13 Dec
2022
13 Dec
'22
4:03 a.m.
The "sticky" bit was quite clever. tell the OS to keep something
memory resident, so you can binary patch the back end without
worrying.
Copy on Write was enormously clever. Keeping FD open across fork/exec
was fantastically clever.
making a null pointer be a valid address was probably not clever
(PDP11) but I expect somebody will explain to me why it was clever.
On Tue, Dec 13, 2022 at 1: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