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

the power. Either that or a craftsman.