In retrocomputing, we’re more often than not turning our eyes towards the low level side of programming. But there are also some high level languages of interest, like Niklaus Wirth’s Modula-2, which may represent the apex of Algol-like languages and is also pretty fast. Also, it’s by Niklaus Wirth!
(Personally, I never did any Modula-2 programming myself, but I learned building compilers by Modula-2 examples from Wirth’s books.)
Reason enough to have a closer look at the compilers that are available on C/PM, like Lawrence Woodman does it in this article.
Modula-2 is a great language in general and is a good choice for programming on CP/M. There are three good compilers available for CP/M which all require a Z80 processor and we’ll compare each in turn.
Modula-2
Modula-2 was developed by Niklaus Wirth and is based on his earlier language, Pascal. It introduces modules to allow separate compilation of related code and data structures which are encapsulated to provide tight control of scope. Modula-2 supports coroutines which make single processor concurrency relatively simple and provides easy access to low-level hardware.
So how many languges has Wirth written NOW? It seems many langauges never seemed
to get past 16 bit code and data. Was this a because the X86 too hard to write larger code
under DOS? Was the langauge design, only good for 16 bit code and data?
Modula-2 was somewhat trapped between Pascal, which was fairly popular in education, and Oberon, which is still around. Much of the success of a languages is also due to luck.
E.g., Modula-2 may have well become the favorite language on ARM systems: Acorn had been developing a POSIX-like multiprocessing system, ARX, in Modula-2 at ARC (Acorn Research Centre, neighbor to Xerox PARC, where Wirth used to be around in the 1980s). Had the development of this gone a bit more straight forward and Acorn had chosen this as the OS for the Archimedes, things may have worked out differently and we may be all well aware of Modula-2. (Moreover, a serious Modula-2 based OS may have provided ARM just the push it needed to make itself known in the business market. And, maybe, the x86 community would have had to follow up on this. I can also imagine Apple to switch from Pascal to Modula-2 in a scenario like this, since you don’t want to be seen trapped in an outdated language.) However, as things were, Acorn went with the more modest ARTHUR project for RISC OS.
Edit: This was actually “Modula2+”:
“This ARX operating system was preemptively multitasking, multi-threaded, multi-user, written in Acorn-extended Modula2+.”
The ARX guys in the US did use what you call Modula2+ though I think they called it ModulaIII, however Acorn in Cambridge used exclusively regular ModulaII on both the Vax and the 32016. I’m actually in the process of tracking down the sources of the compiler from one of the original authors at Cambridge who thinks there may be a copy preserved somewhere. I’ll post if it turns up. We do have the library and some binaries for the 32016 rescued already.
And a playful depiction of what was new in Modula-3 (from this report – apparently someone was in love with their maze algorithm ), most notably exceptions and multiple inheritance:
I still have my Modula 3 book signed by the author Greg Nelson. If I remember they had a “compiler” which generated C source code. I might still have a copy from the DEC Research Centre. Will look through my disks to see if I still have it, when I get back from this caravan trip tomorrow.
Do you remember how Modula-3 was perceived at the time?
Over the course of this thread, I’ve learned that Modula-3 is quite a different beast than Modula-2 and may have been well one of those rare languages which, while not well known on its own, may have defined the future of high-level programming languages (like Simula67). The feature list is quite impressive and is also, where everybody rushed to in the next decade. Or was this more what was already around and Modula-3 happened to pick this up early, but to not great consequence?
So what does having GCC patches do with keeping a langage alive?
A cp/m version or dos version does not need to patched like all this modern
stuff every few months. Of course Windows and other stuff needs to change
the internal stuff to break old software so you have to buy a new version.
Oberon is not a standalone langauge but has its own GUI now.
I’d say, one of the major compilers still enjoying support for a language that isn’t much in use nowadays, but of historical importance, is a nice thing. And I appreciate the engagement of those involved.
[Edit]
Regarding platforms, from the mailinglist (linked in that article):
The devel/modula-2 branch has been bootstrapped on:
Well how about just plain 8086 bare metal.A retro computer by any standard,
could use some new Pascal Style langages with virtual memory of say 512K.
I suspect all of Wirth’s langauges have virtual machine for bootstrapping.
I can’t just pull up a Byte Magazine from the mid 1980’s and order software
any more. Ben.
I don’t think that it’s only about what is better or even optimal. I just found it remarkable that something that maybe rightfully dubbed a “legacy language” is still actively supported by a modern mainstream compiler. (Arguably, there may be some advantages related to this, but this isn’t necessarily for all.) It’s certainly a labor of love.
To me a “legacy language” is one that still runs from punched cards.
FORTAN IV on the IBM 1130 comes to mind. That style of programing
was way different than to day, and one needs to run it on a emulator; but that is new topic.
Ben.
Click “Read” and drop the image onto the reader (or use the file-upload button immediately below)
Click “Run” (below the listing)
(BTW, you can also do entire stacks, either as individual images or packed as a ZIP file.)
Admittedly, this is an edge case…
More seriously speaking, I did this because of the exact reasons you mentioned. I favored better known modern languages in order to allow those who weren’t there to experience this in person (which includes myself) better access to the experience. (FORTRAN and COBOL runtimes were planned, but I ran out of time/steam. But there’s still a chance.)
It is not so much that cards were input, but the fact that you had a limited
character set to use for programing that separated classic languages from
the modern stuff. FORTRAN LISP COBOL.
Right now I am converting Meta II to run on my machine, and update the
character set for ascii 67. All the house keeping in done in rdcrd and wrcrd
like conversion to upper case and line endings are never seen.
Once that is done I can start playing with language development.
I like meta II because you can have Context dependent parsing, rather than
most parsing wanting non-context dependant parsing. Later I will add a symbol table
and variables with ‘white space’ like ‘is this a cat’
Ben.
Having a look at Schorre’s paper on Meta II and all those “(.” and “.)” where we would think of “[” and “]”, respectively, I guess I can see where this comes from.
(Regarding JS for punched cards, I had a similar problem for encoding curly brackets in EBCD. I actually missed that there was already a solution for C and opted for “(*” and “*)”. Also, I’m steganographically cheating an additional upper-case/lower-case mark on these cards, but there are also some heuristics to translate all upper-case sources to something more appropriate.)
Straying off-topic, I had a stab at this when I wrote my own BASIC - rather than allow variable names with spaces I simply removed all non-quoted spaces from the input line before I parsed and tokenised it. It wasn’t quite perfect so in the interests of getting it working now fixing it later, I dropped it - and like so many other things it’s still on the “fix later” list…
Even C had this problem, Back in the Day! ASR 33 Teletypes had no curly brackets (shockingly!), so \( and \) were used, instead. This was not handled by C, however, but by the Unix terminal driver; the actual source file contained { and }. Likewise, the Unix pipe character was ^ (rendered as ↑), and there were several other differences.
(An ASR 35, but the character set matches the ASR 33.)
Prior to the widespread adoption of ASCII '67 (as @oldben mentions), languages were often very limited by the terminals that users had access to, and a variety of tricks were used to make them more expressive. (See also: digraphs and trigraphs.)
), most notably exceptions and multiple inheritance:
