Pascal not considered harmful - was Re: Rich kids are into COBOL

[Jerome H. Fine]

 >Mouse wrote:

>>[...]
>>I'm not at all certain that such a skill is even marginally valuable
>>today.  Who codes much in assembly, much less machine code?
>>
>Those two sentences are only somewhat related.  Knowing instruction
>encoding is important to anyone who is writing or maintaining an
>assembler or disassembler.
>
>Or who is working with malware (either generating it or analyzing it)
>or other deliberately-obscured code.
>
>Or who is designing, building, or debugging hardware.
>
>Or who is writing or maintaining a hardware simulator.
>
>Not as valuable as in the days when dealing with machine code was a
>routine programming task, but, I think, more than "not...even
>marginally valuable".  (Personally, I fall into the first, second, and
>fourth of those camps: I've done assemblers and disassemblers, I've
>picked apart captured malware, and I've done a hardware simulator.)
>
Another (similar perhaps, but definitely distinct) example is the code
which is used to debug software, often called a debugger.  Not only
does the individual who designs, maintains and / or enhances such
code need to be familiar with the actual machine code, in addition
that individual needs to be familiar with how the instructions execute
in both trap and non-trap modes.

Over the past couple of years, I enhanced the Symbolic Debugger
which executes under RT-11 to enable the user to activate additional
code added to the Symbolic Debugger which is able to determine,
then store each executed Program Counter Address within a circular
buffer.  Due to the complex nature of what is required and depending
on whether or not there is also a breakpoint at the instruction being
executed, it takes about 100 instructions to save each Program
Counter Address when saving them has been activated by the user
and there is no breakpoint at the Program Address in question.  At
the same time and with only a few more instructions of additional
overhead, the total number of instructions executed by the user
program can also be counted and displayed by the user.

When the user turns off the activation of the code which saves
the Program Counter Addresses, the user program executes
at normal speed until a breakpoint is encountered - as is the
case with the DEC version Y01.16 of the Symbolic Debugger.

As a consequence, whenever the user enables a breakpoint and the
code stops there, the user is then able to determine the path taken
through the code to reach that specific instruction without having
had to single step through the code.  The three limitations are that:
(a)  Only the last 3000 Program Counter Addresses can be retrieved
(b)  The programs is slowed by about 100 times - as opposed to
       the program being slowed by thousands of times when the user
       single steps through the program and displays each address
       being executed in real time
(c)   A total of  24K bytes of extended memory is used - this is
       offset by a substantial reduction in the Low Memory that
       is needed due to the movement of most of the former Low
       Memory code and data (when only 8 K bytes of extended
       memory was used, but with over 2240 bytes of Low
       Memory for version Y01.16) to extended memory to the
       middle portion of the 24K bytes (along with additional help
       text which supports the new features) since the code and
       data to save the Program Counter Addresses is located in
       the last third of the 24K bytes

Jerome Fine