Data General Fortran 5 is a Real Pig

Humor
1

image

Image originally from Jeff on Flickr: Data General Fortran 5 Ad | Jeff | Flickr

I considered posting this into the Anecdotal Fortran thread, but was hoping more anecdotes would surface if it had it’s own thread.

Data General was a Massachusetts minicomputer firm founded by former employees of Digital Equipment Corporation. The company was also known for its aggresive and tongue-in-cheek advertising. The feeling and mystique of the company is captured in the non-fiction book “The Soul of a New Machine” by Tracy Kidder. The book won a Pulitzer prize in 1982. I’m about one third into the book now, and am completely captivated.

The books follows Tom West and his team of engineers as they rush to build a 32-bit minicomputer, the Data General Eclipse MV/8000. Quoting Wikipedia on the Eclipse’s operating system:

The AOS/VS operating system supported the notion of lightweight “tasks” as well as processes. A single process could start various tasks that would all share a global address space (similar to modern “threads”). Tasks were very easy to use from Data General’s FORTRAN compiler, and allowed faster context switching than using full processes.

Concerning the ad, @vmagnin’s reaction was:

In The Three Little Pigs, Fortran is certainly the one who uses bricks…

3 Likes
2

I’d love to learn more about Data General (Fortran) and it’s rivalry with DEC. The rivalry between Data General and DEC is reminiscent of the competition we see today between the ranks of Intel, AMD, and NVIDIA.

The book is placed into the era where the switch from 16-bit to 32-bit computing has just began. We live in a similar era today, for example with Intel deciding to drop support for its 32-bit compiler, due to the dominance of 64-bit processors, and some Fortran practitioners divided on whether the default integer should be 32- or 64-bit, others attempting to port broken 32-bit programs to 64-bit systems.

1 Like
3

On bitsavers, one can find the Data General Fortran IV User’s Manual (dated July 1974), including a part on Data General’s Real Time Disk Operating System. The runtime library was quite extensive. I was delighted to find functions for bit/word manipulation.

4

At least for Intel and AMD, that rivalry dates back to the 1970s, the same era as DEC and Data General. Nvidia was founded a couple of decades later.

5

I was at DEC during the latter part of the Data General days, and interviewed at DG before I got hired by DEC. The DG Nova 16-bit minicomputers were pretty good, though the DEC PDP-11 series outsold them. The 32-bit MV/10000, meant to rival the VAX, was a spectacular failure, and DG faded from view shortly after its release.

Every minicomputer maker had their own Fortran, often heavily customized. I spent a year pre-DEC working with a PRIME 300 mini, where the file system was written in their Fortran dialect. In the 32-bit world, DG was a non-entity.

For your amusement: TOM PAYNE - I BUILT A BETTER MODEL THAN THE ONE AT DATA GENERAL LYRICS (songlyrics.com)

1 Like
6

The love-hate relationship everyone had with the Fortran extensions! Graphics, screen formatting, system interfaces, databases, bit manipulation, all there on most systems… but almost all were not portable.

Many have no idea how extensively extended everything was and that no major systems came with C at all, but you could not even enter the HPC market without a Fortran compiler standard on your system.

The first web browser we wrote was in Fortran on a VAX. Totally trivial working with sockets and system calls. Anyone remember having to interface any graphics program to your local (usually “Calcomp-compatible”) graphics libraries or just having a protocol to use on the Web, so you cooked your own programs?

But our bread and butter was analytical codes and we had PRIMES, NOS, NOS/VE, COS, Ultrix, SunOS, Solaris, HP-UX, AIX, VAX/VMS, MVS, DG, OS2, MACs, and others I do not remember in the company and clients with OSes we did not have with no network connections to that we had to port Fortran programs to.

All we wanted was standardization but everyone saw their extensions as a strategic advantage or a tool for locking customers in so no one wanted to add new features to Fortran outside of numeric computation. Beware what you ask for – we got a lot of the standardization partly through attrition and Unix/Linux as well as through the Fortran vendors; but what was lost was immense. If the extensions had been standardized and adopted it is hard to believe many of todays languages would ever have evolved. Cray proposed F- (basically, CoArrays) so long ago it is hard to remember but other companies were not selling multi-processor machines and had no vectorization so they wanted nothing like that in the standard, as just one of a hundred examples where the dark side of standardization held things back.

It is hard to even remember that Fortran was the go-to language for graphics for years, for example. The first relational database I used (RIM0) was Fortran. Now if I want to add databases and graphics to a Fortran program I spend five minutes just sighing first.

Standardization was critical. If you had to use any non-standard Fortran you had to put a request in to a group that provided an in-house standard library for all those platforms and they had to add it or you were not allowed to use it in production code – and Fortran had so little that was standard that included things like getting the date and time or listing files in a directory!

Otherwise your first code was your last because you would spend the rest of the time porting it to all those platforms, which changed constantly.

But I still miss some of those extensions, particularly on the VAX. I remember just about everything being available via Fortran.

A bit back when everyone was voting on Fortran logos and considering mascots everything from T-Rex to rabbits came up, but I do not remember a pig being mentioned. Cute add but I do not think it had much of a chance of catching on. Although to this day we calculate a hog factor for our larger codes, but that would be hard to explain and a high factor is not a good thing!

5 Likes
7

Please excuse me while I go into one of my occasional rants on this topic.

On VMS, everything was available from every language! Not just Fortran, but also BASIC, PL/I, Pascal, COBOL, RPG/II, APL and more! This was due to the forward-looking and, to my knowledge unique, “Common Language Environment”. Some of the aspects of this were:

  • The VAX Calling Standard, which specified how procedures passed arguments and returned values, with a standardized descriptor format for things that needed more context (though you could pass even simple integers by descriptor).
  • Every language was required to provide a means to pass or receive arguments by value, reference, or descriptor (in VAX FORTRAN this was the %VAL, %REF and %DESCR prefixes).
  • A common run-time library (a stdlib, if you would), callable from any language
  • System services similarly callable from any language
  • A naming convention that separated user and system namespaces, as well as giving each language its own naming prefix, so no name collisions
  • A common format for return statuses that contained facility identifiers and severity codes

While this started with VAX, it continued with Alpha VMS. I have not seen any platform since be so designed to be language-neutral.

Today, C (not C++) is the closest we can come to a common interface, and Fortran is unusual, if not unique, in standardizing C interoperability. It goes a long way but doesn’t break the language-specific barriers that exist on most platforms.

I was on the VAX/VMS Run-Time Library project for my first five years at DEC, working on both the VAX FORTRAN and VAX Pascal language libraries but also many language-independent routines.

I’ve never understood why later platforms, including UNIX, essentially became walled gardens, fully accessible from only a single language.

9 Likes
8

That is a great concept that would be a dream come true if implemented on all systems. But in Fortran’s case it still depended on those extensions. As C and Unix became more and more common on the STEM user’s desktop X11 was another stab at Fortran’s dominance because so many parts of X11 required pointers, control over pass by value versus reference, pointers, and structures. VAX/VMS had extensions for all of that, and inline comments (which I was hooked on to the point of writing a pre-processor to take them off on other machines so I could use them everywhere) so the OS was great

(DEC had the only high-reliability system with automatic rollover that I every used that worked reliably back when many vendors claimed they had it) . So that is a brilliant design strategy for the OS, but Fortran extensions still played a major roll in making Fortran truly general purpose on that platform, it seems to me.

And their keyboards were several inches wider, which made typing much less stressful on the hands to boot!

I did not know the libraries were standardized across so many languages but there were fees for a lot of them and we had to have Fortran for our cross-platform codes and Fortran was so versatile on the DEC machines we never had a need to buy the others much. In fact, when we made our own WWW browser it was mentioned we might want to use C but we did not yet have it and could not justify buying it just for that when it was so easy in Fortran; plus we knew VAX/VMS Fortran better back then anyway.

I would not want to go back to having to know twenty different commands just to list my files (“CATLIST” anyone?) but evsn so there are so many OS features I still miss. Versioning file systems, access control and access logging better than any newer ACL or file auditing system I have seen since, batch task scheduling far beyond “at” and “cron”, … I never imagined that this many years later Unix-like systems would still be missing equivalent interfaces.

The language-agnostic OS was something I enjoyed without every actually appreciating that it was there. The NOS LIBRARY archive file that could contain your text, object files, executables, … made such a nice single-file project method; and you could add it to your library path and the routines were automatically available to any load command and the commands were part of your execution path without having to unarchive the file was nice too; and on and on. I can remember using NOS/VE and NOS machines where you could invoke a script written in CCL in line mode or screen mode with help text displayed under the options positionally or by keyword; when I first used sh and csh they seemed so primitive largely because of lacking that; but assumed within a few years Unix would have equivalent features …

I think I am going to play with extending bash to have the CCL-like automatic screen interface. After years of using Unix/Linux I still miss that and no one seems to have every done anything equivalent except to provide dialog-like interface builders. And the time(1) builtin command in
csh/tcsh could create a small job accounting like the Cray ja(1) command could do which was great for understanding resource usage in heavily loaded HPC systems and so on.

2 Likes
9

The Ada '83 standard described interoperability for C, Fortran and COBOL. There were some mistakes in the Fortran description, including things such as REAL*4. I sent edits to the Ada committee, but I haven’t checked whether they’re in the revision currently under development.

10

Do you think the back-end languages, such as LLVM, are going to play that role in the future?

11

No - it isn’t the back-end which helps here.

12

Looks like David Ogilvy’s firm did that ad, although I suppose there were many imitators of their style in that era. It’s a very good ad, and uses textbook methods like leading with all of the negative features, which worked well back when the majority of the population knew how to read and had an attention span of more than 14 seconds.

13

I won’t claim that it rivals the VAX, but I’ll note that CUDA is supported across a number of languages. While most people think of CUDA as a C-based language, kernel syntax and APIs are supported in Fortran and Python, and I think the support in Julia and Rust is at least decent.

I am especially fond of our API support in CUDA Fortran, because while I don’t write a lot of CUDA kernels, I call asynchronous data movement routines and linear algebra libraries quite a bit.

14

Just found this thread.

I did a lot of work using a 16-bit DG Eclipse S/230 system in 1978-79. The lab was just completing converting to it from a DEC PDP-15. Really liked the AOS operating system. Apparently it was largely written in a PL/1-like dialect. Had a directory-based file system like unix (and easier to use than TOPS-10 sub-file directories). The ‘speed’ text editor was teco-like, so pretty easy for anyone who had used teco to adapt to. I do recall that the Fortran V compiler had an issue with external names that were longer than 5 characters not being unique. This got fixed at some point, to the relief of all, because up to that point we had to maintain a separate branch of our code with mangled names.

A few years ago, a relative of my son-in-laws father was a guest at my daughters wedding. He had worked at DG for a while and is mentioned in Soul of a New Machine! Since I had a copy of the book, he was happy to autograph it for me. (We had some other mutual interests, so we talked a lot that weekend. Fun time!)