[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on ProDOS SmartPort drive remapping



"mdj" <mdj.mdj@gmail.com> wrote in message 
510c80ca-4a35-4c6c-9ff9-4398e93c8958@s8g2000prg.googlegroups.com">news:510c80ca-4a35-4c6c-9ff9-4398e93c8958@s8g2000prg.googlegroups.com...
> mdj@bob:~$ /bin/true --version
> true (GNU coreutils) 5.97
>
> Careful what you wish for - if a program that does *nothing* successfully
> can reach version 5.97, who knows how far AlphaPrint can go ...

I'm guessing that the 5.97 version number is related as much to the GNU 
coreutils as anything, but it reminds me of a funny story from my IBM 
mainframe days.

IBM had a program called IEFBR14, which was basically a NO-OP program useful 
for reasons which are too esoteric to discuss here.

The name pretty much described the program. It consisted of one line of 
assembler which generated two bytes of executable code:
    BR  R14
This basically meant "return to caller", since by convention the return 
address on entry is stored in register 14.

This incredibly "complex" program still managed to get a bug report raised 
(and accepted) against it!

The problem was that also by convention a program's return code should be 
loaded into register 15, but in IEFBR14 it still contained the value on 
entry, which just happens to be the program's entry point address! So the 
do-nothing program was always reported as ending with an non-zero error if 
anything checked the return code! (The fix doubled the size of the program 
to four bytes! Register 15 was cleared before returning.)
-- 
Peter Watson
-- Write to MS-DOS disks on the Apple IIgs?
-- Impossible!  ;-)