On 24/04/2018 20:00, druck wrote:
> On 23/04/2018 21:02, Gareth's Downstairs Computer wrote:
>> On 23/04/2018 20:12, druck wrote:
>>> On 22/04/2018 21:54, Gareth's Downstairs Computer wrote:
>>>> On 22/04/2018 21:44, druck wrote:
>>>>> On 22/04/2018 12:22, Gareth's Downstairs Computer wrote:
>>>>>> For example, due to operator precedence, parentheses might
>>>>>> prove to be unnecessary, but you'd be justifiably miffed
>>>>>> if they disappeared from the source code, as source code
>>>>>> has human understandabilty considerations, and so
>>>>>> it becomes necessary to
>>>>>> insert a special form of NOP in the compiled code to
>>>>>> represent the parentheses; only one NOP for each pair.
>>>>>
>>>>> No, only the source needs such human readable information, it
>>>>> should not appear in compiled code, or even in the output of hand
>>>>> written assembler.
>>>>
>>>> Not wishing to be rude, but may I suggest that you read this
>>>> thread from the top, for the discussion, in my terms at least,
>>>> is for the source to be the compiled code!
>>>
>>> I have, and your intention makes no sense to me regardless of what
>>> architecture it's on.
>>
>> "ListBack", the name I have somewhat too early coined, is intended to
>> solve the worldwide problem of software support long after the sources
>> and design notes have been lost, or to support obsolete equipment
>> containing firmware for which no manufacture support is forthcoming.
>
> 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.

--- SoupGate-Win32 v1.05