[m4] Version 1.4.16 released - new package

hdr-mark

New Member
You'll find a version of GNU m4 up on hummypkg now. I needed this to compile the at daemon, and it may be useful to others for on-the-Humax compilation.

I had to cross-compile this from my Linux box: when compiled on the HDR, it failed with "Stack overflow" on any type of invocation.

Please don't ask me for help with m4 as I only have the vaguest idea what it does, but it seems to work.
 
If you don't know what it does, what's it for?

From my original message: "I needed this to compile the at daemon". It's a macro processor, and was a prerequisite tool to compile the package. I'm not 100% clear on what it does, but I am 100% clear that I needed it. :D
 
We have a convention that package names are italicised, it makes the text a bit more readable.
 
This looks fairly similar to a meta-assembler I used on a VMS system in the '80s. We hand-crafted a special-to-purpose control system, which executed 40-bit instructions (five 8-bit EPROMs in parallel) and needed programming somehow.

The solution was in the form of this meta-assembler, which had to be bought in as Fortran source and one of our systems programmers compiled it and made it work on our VAX mini (it was regarded as a minicomputer, but it still occupied an air conditioned computer centre and we spoke to it by time sharing on VT100s scattered around the building communicating by 9600 baud serial links - actually I think we had three down there, and don't forget these were the days when PCs were barely a twinkle in Bill Gates' eye).

The meta-assembler took as input a file which set up a huge set of definitions for macros and bit field replacements, and then assembler code that used the macros to define a 40-bit data pattern corresponding to the code. The power was that it could also use symbols and do calculations when defining the bit patterns, so you could define a jump to a label, for example, without having to know what address the label would be at beforehand. Using the meta-assembler to create an assembly language for our controller was right up my street. Waiting for it to run a compilation to then debug the error messages, in the dark and warm of a Tempest-shielded terminal room after lunch, was the stuff of happy dreams.

Such was the blistering power of solid state electronics in that day and age, that our controller managed a whole 10 million instructions per second, but that was using a 40-bit instruction bus and separate data pathways so most things happened in one clock tick. The fastest Z80 (my hobby micro) was 4MHz, but had only an 8-bit bus for instructions and data, so one instruction took at least 4 clocks (and sometimes many more). The 68000 was around then, and IIRC had a 16-bit bus.

The controller in question handled the communications on a 1553B serial bus - in many ways not unlike 10Base2 Ethernet, and 1553A flew on the Space Shuttle. Special interface chips handled the external signals and serialising/deserialising, but they had to be told what to do, and the protocols required that a reply was sent within a few microseconds of a valid packet being received. The lead design engineer had designed the controller architecture with this in mind, but looking back I don't think it was at all certain. It fell on me to figure out how we could detect the incoming packet and validate it fast enough to send the appropriate response within the required window, and that involved triggering off the outgoing packet before working out what the outgoing packet should say. I spent a working weekend alone with a whiteboard covered in flowcharts to sort that one out, counting the clock cycles required on each path and balancing them out so none took too long.

The darling of home computing was the Acorn Archimedes, which ran on an early RISC chip from ARM (the systems programmer I spoke of had one, and I went to admire it).

Back to the plot though, and I *think* m4 does symbolic replacement and macro expansion without doing the bit-field replacements of an assembler, so you could effectively define your own intermediate-level language which creates a lower level code to then pass on to a normal compiler (or as commands to a shell, for example).
 
Back
Top