I also used the TopSpeed Modula-2 compiler. I did some stuff like 3D wireframe animation.
At one point, I used the built-in assembler in MS-DOS's DEBUG.COM to write a Bresenham line drawing routine, targeting the frame buffer directly.
Then I took a hex dump of the code, and planted it as hex inline assembly code into a Modula-2 function. Rubeyes, it worked.
One project was an implementation of the Core War game. I made it nice with a split-pane window showing the dueling programs as a pair of step debugger windows showing a disassembled section of memory with the current instruction highlighted.
The commercial PC/DOS compiler was a terrible buggy mess. I had the misfortune to use TopSpeed Modula-2 and it involved going into the compiled code with a Hex Editor and re-assembling it.
I remember good old times when I used ZX Spectrum (actually it was 100% compatible soviet-clone).
I dreamed to create a game. That's why I actually started programming.
I wanted to create animation.
When I started with Basic I noticed that Basic interpreter is way too slow to update video memory (even for fraction of screen).
Then I discovered world of compiled languages with Pascal. It was much more fun than Basic but still too slow to update video memory.
Then I moved to assembly language (actually I only had list of opcodes and I had to put them in memory directly). It was much more fun than Pascal and speed was great but still not enough for animation if you write straight-forward implementation.
Then I discovered that if you put performance-critical code into lower-memory addresses it runs much faster.
Unfortunately, I didn't finish my research because I had no access to internet and books.
Yeah the real problem with Modula 2 on the Atari (and I imagine this held for the Amiga as well) was that the OS syscalls were really built for C. And all the documentation was for C.
On the Atari, in GEM, there's just a boatload of C unions used for UI elements. And void pointers galore. So not friendly to Wirth style languages which have very strict static typing rules.
That and getting documentation in those days was also a nightmare. Everything was in books/manuals, and it's not like you could just get them from Amazon or even a local bookshop. And books were expensive. And it's not like my Modula 2 compiler manual had good documentation on the OS syscalls, etc. It didn't even include a real full set of bindings.
Somewhere out there there's an ST Format issue with a printed letter from my 14-year old Canadian rural-living self begging for help finding documentation on the Line A graphics calls for the ST.
Coupled with compiling with a floppy based system because hard drives were unaffordable. Challenges.
By the time I got my hands on a C compiler and decent documentation I had moved onto Linux on my 486. The 90s were very much a different era from the 80s!
This is, amusingly, a lot like Modula I, circa 1979. That had language support for device registers, cooperative multiprogramming, and interrupts. A very nice way to program a PDP-11 at the bare metal level.
I used to do some systems programming with then M2 Amiga Modula-2 compiler.
They had a complete mapping to the systems libraries and I suppose for the general learning experience M2 is more pleasant than C, although that works as well, of course.
There was quite a lot of M2 public domain software at that time on the Amiga so that it should be possible to find good examples.
That said, system programming on the Amiga is for good or bad much closer to the hardware than e.g Linux, so prepare to see a lot of guru meditations along the way when you have slightly mishandled a pointer or a data type, and there are a lot of pointers ;-)
Compile all the processes together, allocating all resources at compile time. Modula I had device register access, interrupt access, cooperative multitasking (async, the early years) and it worked moderately well on PDP-11 machines.
Yes, I did use it. We wrote an operating system in it at an aerospace company.[1] It didn't work out well. Sort of OK language, weak compiler, not enough memory given the poor code generation. It was just too early to be doing that back in 1978-1982. We got the thing running, and it was used for a classified high-security application, once.
It was easy to give your customers the proper interface files (they were compilable), so they could code against your interfaces. They are much lighter than the object files (it was the time of the floppy disk and 2400 modems).
One point of having interface files separate is tools like `make`. If the interface file's timestamp did not change, the interface is the same.
It would probably be nicer to have two compilation artifacts, the extracted human-readable interface part and the object-file implementation part.
It (in my case TopSpeed Modula-2) was waaaay faster than e.g. Borland C++ wading through endless .h files.
I remember I had to convert this to C in a hurry because new features had to be added. Doing it in assembler was just about unthinkable. The entire project consists of nearly 100 assembler files and resulted in about 90 files once translated into C.
This was a marathon run and once the entire project was translated and working the focus was narrowly shifted in the direction of adding functionality rather than optimizing the code.
This code was running on an 8051-derivative. Performance was important. You are always counting clock cycles on these systems. I think that if you look at the resulting machine code with the relevant variables mapped to the data memory space the modulo statement doesn't really do any better than a spelled-out conditional statement. In fact, it could be a couple of clock cycles slower (just guessing).
Again, it's been a long time. I can totally see looking at the generated assembly and saying something like "That's as fast as it it going to get. Move on!".
We all make less-than-elegant code at one point or another. Hopefully not too many times. :-)
At one point, I used the built-in assembler in MS-DOS's DEBUG.COM to write a Bresenham line drawing routine, targeting the frame buffer directly.
Then I took a hex dump of the code, and planted it as hex inline assembly code into a Modula-2 function. Rubeyes, it worked.
One project was an implementation of the Core War game. I made it nice with a split-pane window showing the dueling programs as a pair of step debugger windows showing a disassembled section of memory with the current instruction highlighted.
:)
reply