Author: dvalin Date: To: dng Subject: Re: [DNG] filosofies behind programming languages
On 04.11.24 02:26, karl@??? wrote:
> Steve Litt: > ... > > Assembler: Anarchy. > ... > > Aww, now you are a little unjust, you can produce anarchy or rather > chaos in any language. > > Anarchy is "a utopian society of individuals who enjoy complete > freedom without government", so I'd associate anarchy more with > bare metal programming, i.e. no operating system. > > I'd more associate assembler with the grains in a well made wooden > creation, which the artist has poured his/her love into.
Karl, you speak like a fellow craftsman.
My 30 year embedded career, now 16 years behind me, began exclusively
with assembler implementations of multi-threaded Call Control software
for national carrier digital trunk telecommunications - explicitly 30
channel 2.048 Mb/s PCM primary multiplexers in the incipient
plesiochronous network predating todays good stuff.
German colleagues used Nassi-Schneidermann diagrams to design the state
machines, then filled in hand-crafted assembler to implement the intent.
Sent to Munich to learn, I found it tedious to redo all that daily as
design changes blew in the wind. So, instead, I implemented an assembler
macro with internal conditional assembly to test any possible input,
dependent on the provided parameters, and a suite of macros to implement
every required communication or hardware output. That gave me a Problem
Domain Language, allowing me to abstract totally from the "How" to the
"What" - and finish the day's recoding before lunch, without any sweat,
and rarely an error, after the macros were debugged.
The first implementation handled the 30 channels on an 8085 running at
6.144 MHz, so maybe 0.5 MIPS or so. With inputs arriving for all 30
channels each 2 mS, there was only 62.5 uS per channel on average
(plus a bit of houskeeping) so it was only expeditious handling of "no
action" input which freed up cycles for work to be done on active
channels. The second generation used a couple of 8051s, one primarily as
a FIFO buffer between the synchronous system and the call control
processor, now good for about 0.6 MIPS, even at 12 MHz clock.
Apropos exception handling, the design brief was "Switch on and run
unattended for 25 years." so robustness was critical. All that I did was
clip input event destination addresses to the set of extant state
machine instances. It was not necessary to filter input events to a set
of permissible values, as any event not explicitly handled at the
current state passed harmlessly through like a date seed through a
camel. A background ROM CRC check served for detecting the most probable
hardware failure, and a hardware watchdog caught any EMI-induced program
counter excursion. Thousands found heavy use in Australia's national
telephone network, and the only feedback was a request for a software
customisation, after some years, to better handle some weird rural
telephone exchanges.
Dated? Not so much. Three decades later, I implemented an improved
version of this limited "compiler" (sans most error checking ;) for the
AVR ATmega64. The freedom and efficiency of Problem Domain programming
was much appreciated by the team. On a larger system, we had a
heterogenous state machine population with a hundred Extension
instances, a dozen Trunk instances, and a floating population of
ephemeral Call instances, instantiated as needed. How in assembler, with
zero use of malloc? A hard Real Time system *must* always have needed
resources. RAM for the instance variables was provided as an adequately
sized array of structs. (Yes, gas has a .struct pseudo) Allocation
consisted of grabbing the free list head, in a fully deterministic
fleetingly fast operation. No latency issues.
The OS was a DIY event scheduler, running the adrdessed SM instance for
each input event, at the instance's current state. Inter-instance
communication was available via the event FIFO or another priority
queue. Two event-generating timers were provided per instances by the OS
timer service. So all we needed was the GNU toolchain, cross-compiled
for the target, and pizza. I did tolerate team members editing on MS,
then compiling on a Linux server.
OK, for management comfort, we did spend A$250k per seat for a fancy SDL
(Specification & Description Language) compiler suite which accepted
graphical input for maximum Point & Grunt appeal, but after heading the
trialling and purchase effort, I didn't ever use it on a project.
I made the mistake of employing a CS graduate once. Only once. I suspect
it takes an engineer to do the job with 1/10th of the hardware and 5% of