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” →

Giving The Arduino Deques, Vectors And Streams With The Standard Template Library

October 22, 2012 by Brian Benchoff 20 Comments

The Arduino IDE is extremely similar to C++, but judging from the sketches you can find on the Internet, you’d never know it. Simpler Arduino projects can make do with just toggling IO pins, reading values, and sending serial data between two points. More complex builds fall into the category of real software development, and this is where the standard Arduino IDE falls miserably short.

[Andy] saw this lack of proper libraries for more complicated pieces of software as a terrible situation and decided to do something about it. He ported the SGI Standard Template Library to bring all those fun algorithms and data structures to any AVR chip, including the Arduino.

Going over what’s included in [Andy]’s port reads just like a syllabus for an object-oriented programming class. Stacks, queues, and lists make the cut, as do strings and vectors. Also included is just about everything in the and headers along with a few Arduino-oriented additions like a hardware serial and liquid crystal streams.

With all these objects floating around, [Andy] says it will make an impact on Flash and SRAM usage in an AVR. Still, with all the hullabaloo over faster and larger ARM micros, it’s nice to see the classic 8-bit microcontroller becoming a bit more refined.

Operating Systems Development With The Raspberry Pi

September 2, 2012 by Brian Benchoff 20 Comments

Even though the Raspberry Pi has, from the very beginning, been touted as an educational computer, we’ve seen neither hide nor hare of coursework, lesson plans, or even computer sciencey tutorials using the Raspi. We’re guessing academia works at a much slower pace than the average hardware hacker, but [Alex Chadwick] at Cambridge University has managed to put together an online tutorial on developing an operating system from scratch for the Raspi.

The goal of this tutorial is to throw a budding Raspi tinkerer into the strange and confusing world of registers, hexadecimal, and ARMv6 assembly. After going through the necessary toolchain, [Alex]’s tutorials cover blinking the ‘OK’ LED on the Raspberry Pi using only assembly.

The OS development guide goes on from there to include drawing graphics on the screen and even accepting input from a USB keyboard.

It’s important to point out what [Alex]’s tutorial isn’t; even though this series of tutorials goes through manipulating the bare metal of the Raspberry Pi, don’t expect to be porting UNIX to the Raspi after going through these guides. That being said, after completing these tutorials, you’ll be in a fabulous position for building your own homebrew OS on the Raspberry Pi.

Monitoring Software Builds With A Traffic Light

February 12, 2012 by Brian Benchoff 21 Comments

[JD] at isotope11 was looking for a way to get instant feedback whenever a developer broke a piece of software they were working on. After finding a 48 inch tall traffic light, he knew what he had to do. Now, the entire development team knows the status of their code from a traffic light hanging in the corner.

isotope11 runs a continuous integration server to do the quality assurance on their software projects. It’s a lot more flexible than the ‘compile and pray’ setup we’re used to, but then again C isn’t very well suited to test-driven development. When one of [JD]’s developers breaks a piece of code, the CI server will send a warning to an Arduino where all the electronic magic happens.

To light the traffic light, [JD] used a few relays to drive the 120 volt bulbs in the traffic light. The traffic light is very easy to read – red means something is broken, green means everything is alright, and yellow means a test suite is being run.

Check out the video of [JD]’s TDD visualization after the break.

Continue reading “Monitoring Software Builds With A Traffic Light” →