This Is Not Your Father’s FORTRAN

October 26, 2015 by Rud Merriam 109 Comments

I learned to program FORTRAN IV in the spring of 1968 while working as an engineering technician in water resources. One of the engineers knew of my interest in computers and asked if I would like to learn FORTRAN. He needed to calculate the biological oxygen demand in streams but didn’t have any interest in programming. I jumped at the chance.

This was the days of big iron when the term computer meant a room full of heavily air-conditioned equipment. The State University of New York at Buffalo had an IBM 704 but they soon upgraded to a CDC 6400. To help pay for it they were inviting people to attend a seminar on FORTRAN so they could use the system. My job was with a small State of NY office and getting approval for me to attend was surprisingly easy.

Off I went for 6 weeks of training on one night a week. I still have my black “A Guide to Fortran IV Programming” by [Daniel McCracken]. For years, this was the FORTRAN bible, commonly referred to as just “McCracken”.

The programming went well and somewhere out there is a very old paper with a reference to the results it generated about the Chadakoin River flowing through Jamestown, NY.

This is FORTRAN’s strength – scientific calculations. It’s name says it: FORmula TRANslation.

Origins and FORTRAN IV

[John W. Backus] suggested to IBM a language to replace assembly language. Development began in 1953 for the IBM 704 and the project reached fruition in 1957. Not only was it the first general purpose high-level language, just beating out COBOL and LISP, but its compiler optimized the code since it needed to compete head-on with assembly language. It was the C compiler of its day in that regard.

That was not the only reason it attained success. Reducing the number of punched cards needed for a program by a factor of 20 over assembly helped considerably.

In those days, you needed to use a key punch to create a deck of punch cards. To be really good you had to know how to create a programming card that would let you skip through the fields on a FORTRAN card, or how to edit a card by duplicating it and holding one of the cards in place while you typed in new characters. Because of my fascination with computers I’d taken a key punching and automation machines class in high school so I was all set.

Continue reading “This Is Not Your Father’s FORTRAN” →

C++ Turns 30 – Looking Forward To The Future

October 17, 2015 by Rud Merriam 37 Comments

[Bjarne Stroustrup] introduced C++ to the world on Monday 14th October 1985 at the ACM annual conference on “The Range of Computing”. On its 30th anniversary [Bjarne] reviewed the history, his experience, and his thoughts on the future of the language in an interview. Also on that day the first edition of his book, “The C++ Programming Language” was released. It’s now available in a 4th edition. The title differed only in the “++” from the classic C book by [Kernighan] and [Ritchie] that graced the desktops of a multitude of C programmers.

The first versions of C++ were compiled with CFront, a compiler that generated C code which was then compiled as normal. Around the 1990s, it’s unclear when, numerous native compilers became available, notably for PCs, which lead to explosive growth from 400,000 users to an estimated 4.4 million today.

One of the frustrations [Stroustrup] expresses is how C++ is viewed by developers,

… a problem that has plagued C++ forever: Poor teaching and poor understanding of C++ even among its practitioners. There has always been a tendency to describe C++ as some odd variant of something else.

Soon the standards committee is meeting to discuss C++17 in Hawaii. Fair winds and bright skies look to be in the future of C++.

Code Craft: When #define Is Considered Harmful

October 16, 2015 by Rud Merriam 95 Comments

An icon of Computer Science, [Edsger Dijkstra], published a letter in the Communications of the Association of Computer Machinery (ACM) which the editor gave the title “Go To Statement Considered Harmful“. A rousing debate ensued. A similar criticism of macros, i.e. #define, in C/C++ may not rise to that level but they have their own problems.

Macros are part of the preprocessor for the C/C++ languages which manipulates the source code before the actual translation to machine code. But there are risks when macros generate source code. [Bjarne Stroustrup] in creating C++ worked to reduce the need and usage of the preprocessor, especially the use of macros. In his book, The C++ Programming Language he writes,

Don’t use them if you don’t have to. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer.

As C retrofitted capabilities of C++, it also reduced the need for macros, thus improving that language.

With the Arduino using the GNU GCC compilers for C and C++ I want to show new coders a couple of places where the preprocessor can cause trouble for the unwary. I’ll demonstrate how to use language features to achieve the same results more cleanly and safely. Of course, all of this applies equally when you use any of these languages on other systems.

We’re only going to be looking at macros in this article but if you want to read more the details about them or the preprocessor see the GNU GCC Manual section on the preprocessor.

Continue reading “Code Craft: When #define Is Considered Harmful” →

Code Craft: Subtle Interrupt Problems Stack Up

October 9, 2015 by Rud Merriam 42 Comments

[Elliot Williams’] column, Embed with Elliot, just did a great series on interrupts. It came in three parts, illustrating the Good, the Bad, and the Ugly of using interrupts on embedded systems. More than a few memories floated by while reading it. Some pretty painful because debugging interrupt problems can be a nightmare.

One of the things I’ve learned to watch out for over the years is the subtlety of stack based languages, like C/C++, which can ensnare the unwary. This problem has to do with the corruption of arrays of values on a stack during interrupt handling. The fix for this problem points up another one often used by black hats to gain access to systems.

Continue reading “Code Craft: Subtle Interrupt Problems Stack Up” →

Hack An Editor: Fonts For Programming

September 2, 2015 by Al Williams 41 Comments

We’ve recently noticed two different fonts aimed at programmers, each with a different approach to editor customization. The first, Fira Code, transparently converts common programming digraphs into single characters. For example, <- becomes an arrow and != (or <>) becomes a proper not equal sign. The other font, Hack (can’t argue with the name), aims to make commonly confused characters distinct. For example, the zero glyph has a very distinct appearance from the letter O.

It is pretty easy to understand how Hack works, but Fira seems a mystery at first. Your C++ compiler expects <- not an arrow, right? Fonts support ligatures–sequences of two symbols that run together (like æ). Clever use of these ligatures means that the compiler still sees -> but the screen displays an arrow.

Continue reading “Hack An Editor: Fonts For Programming” →

Amazon’s AI Escapes Its Hardware Prison

August 4, 2015 by Brian Benchoff 47 Comments

It’s the 21st century, and we’re still a long way from the voice-controlled computers we were all promised in the 60s, 70s, 80s, and 90s. The state of voice interaction has improved, though, and Amazon’s release of the Alexa Skills Kit (ASK) is another sure step towards a future of computers that will pay attention to you. This allows any hardware to become Alexa, your personal voice assistant with the ability to do just about anything you command.

Up to this point, Alexa was locked away inside the Amazon Echo, the ‘smart’ cylinder that sits in your living room and does most of what you tell it to do. Since the Amazon Echo was released, we’ve seen the Echo and the Alexa SDK used for turning lights on and off, controlling a Nest thermostat, and other home automation tasks. It’s not Google Now, Microsoft’s Cortana, or Apple’s Siri that is behind all these builds; it’s Amazon’s Alexa that is bringing us into a world where Star Trek’s [Scotty] talking into an old Mac is seen as normal.

Right now, the Getting Started guide for the Alexa Skills Kit is focused more on web services than turning lights on and air conditioning off. Sample code for ASK is provided in JavaScript and Java, although we would expect 3rd party libraries for Python to start popping up any day now. If you want to run ASK on a Raspberry Pi or other small Linux computer, you’ll need a way to do voice capture; the Jasper project is currently the front-runner in this space.

We hope this changes the home automation game in a couple of different ways. First, the ASK processes everything in the cloud so very low power devices are now ready for some seriously cool voice interaction. Second, Amazon’s move to open up what you can do with the software backend means a community developing for the hardware could eventually exert pressure on Amazon to do things like making the system more open and transparent.

Already working on some hacks with the Echo or ASK? Send in a tip to your write-up and tells us about it in the comments below.

Talking, Foot-Pedal-Controlled Bench Probes For VirtualBench

July 29, 2015 by Kevin Dady 2 Comments

Developing new products can be challenging during the debug and test phases, often you have your head down trying to probe the lead of some SOT23 transistor, and just when you get it, you scan your eyes up and find that your multimeter is measuring resistance and not voltage.

[Charles] had this issue compounded on his NI Virtual Instrument. It has an interface totally driven from a PC, which may or may not be in a convenient location to mouse around. Luckily NI just released an API for the 5 in one lab test station and [Charles] quickly whipped up a python wrapper which gives him ultimate control over the instrument.

Tying the script to a USB footpedal and adding some text-to-speech capabilities using google’s API [Charles] is easily able to switch from continuity to voltage to resistance and anything else he pleases with just the tap of a foot and listening to the measurements, making sure he never takes his eyes off the work which is risking a short.

Join us after the break for a quick video demonstration.

Continue reading “Talking, Foot-Pedal-Controlled Bench Probes For VirtualBench” →