Apologies where they are due

Never.

Closest I came to that was assembling my SS-50 bus 6809 system from a collection of boards and a bag full of chips and debugging the result with a multimeter and logic probe. Fortunately, I'd gotten an EEPROM programmer card as part of the system because I very soon decided its memory-mapped 64 x 16 display was far too small for what I wanted to do, replaced it with an 80 x 24 MC6845-based card and rewrote the monitor to suit it. Since I also had to make my own character generator (another 4K EEPROM (2716?) I used the top 256 characters as a crude graphics system.

Later, I expanded the system from 2 5.25" floppies to four, which involved a bought-in Windrush disk driver card, which I mounted on an SS-50 proto board with my own-designed address decoding and buffering. That was a FLEX09 system, so when Microware's OS/9 appeared of course I used that for several years before moving to my current kit, which all runs Fedora Linux apart from the RPI on Raspbian.

My professional career was first on ICL mainframes and then on an odd mix of fault-tolerant systems (Tandem NonStop and Stratus), database design & tuning, comms (X.25, TCP/IP and a little SNA (ugh!)) on anything from AS/400 (nice kit) to a variety of UNIX systems (DEC, NCR).

--
Martin    | martin at 
Gregorie  | gregorie dot org

These days I would recommend IO over Self.

--
Andy Leighton => andyl@azaal.plus.com 
"We demand rigidly defined areas of doubt and uncertainty!" 
   - Douglas Adams

On a sunny day (Tue, 24 Apr 2018 09:05:57 +0000 (UTC)) it happened Martin Gregorie wrote in :

Exactly same here, 6845 80x24

used a 2732 EPROM for characters, used the upper set semi-graphics characters as in Ceefax (Videotext for Germans) graphics, not much known in the US I think.

Actually I also wrote a whole lot of that ceefax stuff, still using it today for satellite TV as news source and program guide, if available.

quite more powerful than the normal TV ceefax display, has macros, page save and load, click on numbers to get a page, etc. I *think* somebody had a look and make a not so good copy online for the national network. I never patent anything, patents get to be a bit insane these days, blackberry suing others for displaying number of unread emails, seems they have a patent on that, completely obvious to anybody, should never have been granted. Apple also patents anything however silly it may be. That all will have to change some day. I am a strong open source advocate.

I always was, and still am, a Slackware user. I have Debian on some partitions too. Slackware a bit more a one man show, and really linear to follow. Debian on raspi is making things easy for many with apt .. but I prefer compiling from source. I would not dare do an apt-get upgrade on some of my raspis, it does get confused. Soon as it had the card and was running it was also changed.

Panteltje Linux? Thought about it, too much work. Same for writing a web browser, moving target, started, standard changed while I was coding ;-)

Another, Lattice XO2, $39.99:

Two conflicting goals a cpu only talks one language - machine code. therefore any high level language needs either a compiler that translates your source into machine code - & that can only be reliably reversed back into Assembler. Or an interpreter (which is in machine code) which reads each instruction in the source & then executes the sequence of instructions needed. this process takes time. you idea of using "Ambiguous NOPS" to flag unnecessary information such as parentheses would still incur a speed penalty as even a NOP takes some time to execute.

--
Theory is gray, but the golden tree of life is green. 
		-- Goethe

You're paying attention.

Well done!

10/10

A++

:-)

Sorry, mis-read you.

I did explain this further back up the thread, based on string accumulation back to the HLL.

My second job contracting for Deutsche Aerospace, after writing the cabin software for the A330/A340, was gaining retrospective JAA certification the earlier A320's cabin software (written before this was a necessity). This involved reverse engineering large amounts of 68000 assembler to produce a low level design, and verifying that against the requirements. So I have some experience of exactly what you describe above, in safety critical software.

The use of ambiguous instructions to indicate parenthesis, or anything else, would have been useless, or even worse than useless. Similarly even when the full source code is available, you do not rely on the comments, as they are often out of date or just wrong. There is only one thing that tells you want the code is doing, and that is the code itself.

The steps you need to take are:-

• Forensically examine the code

• Reproduce the design

• Test against that design

• Update the design

• Update the code

• Retest the code

---druck

Perhaps we are agreeing at cross purposes based upon differing experiences?

But perhaps not, as 5 years ago I was in a contract to document an existing railway system (no names, no pack drill), but that was merely to produce page after page of COMPLETELY POINTLESS documentation to describe each function, its inputs and outputs, merely to satisfy some QA requirement; documentation that no softy will ever read.

What I also found to be unprofessional was their habit of testing a CANBUS installation just by observing its external behaviour.

And that only tells you half of the story. The reason I pointed to the work of Alastair Reid and others is that to reason about what the code is doing, you have to know what instructions mean. That is surprisingly tricky. Even simple arithmetical operations get difficult when you start talking floating point, and then there's questions about accelerators, system control, caches, MMUs, system on chip components...

The pathways from ISA descriptions to formal models allow reasoning about what the program does to the state of the system, whether that is the desired outcome and whether it is well-defined for all inputs. They are very handy in finding architectural bugs.

Theo

That's why you don't just look at it to figure out what you think it does, you write tests to ensure it does what you think it does.

---druck