13 Dec
2022
13 Dec
'22
11:46 a.m.
There was a story that old hands would torment newcomers to the IBM 650
by tinkering with the optimizer to make it as slow as possible (and, with
rotating drums, that could be VERY slow). Then they'd look at the
newcomer's code, make a trivial change, run it with the real optimizer,
and get dazzling improvements.
I also recall punched card bootstrap programs for the IBM 7094 that
would load column binary when run column binary, and load row binary
when run row binary. -- jpl
On Mon, Dec 12, 2022 at 10:53 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 13 Dec 2022, Rudi Blom wrote:
I vaguely remember having read here about
'clever code' which took into
account the time a magnetic drum needed to rotate in order to optimise
access.
Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program)
on the IBM 650; the programmer wrote the code "straight down" and SOAP
reordered it for rotational latency.
Similarly I can imagine that with resource
restraints you sometimes need
to
be clever in order to get your program to fit. Of
course, any such
cleverness needs extra documentation.
Try writing a bootstrap program in 512 bytes :-) Self-modifying code was
the order of the day...
I only ever programmed in user space but even
then without lots of
comment
in my code I may already start wondering what I
did after only a few
months
past.
You could be clever in kernel space too, such as taking advantage of
the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e.
read/modify/write.
-- Dave