[TUHS] Re: Clever code

[TUHS] Re: Clever code

[Rudi Blom]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

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.

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.

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.

Cheers,
uncle rubl
-- 
The more I learn the better I understand I know nothing.

[-- Attachment #2: Type: text/html, Size: 800 bytes --]

[TUHS] Re: Clever code

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Mon, Dec 12, 2022, 8:32 PM Rudi Blom <rudi.j.blom@gmail.com> 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.
>

Yes. Many ways this was done. Biggest ones were interleaving and striding.
Interleaving allowed one a little processing time for each sector while the
disk fpu. So the next logical sector isn't the next physical... and the
sectors are numbered in adjacent tracks to take into account rotation and
seek times.... there is a lot of research here...

Warner

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.
>
> 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.
>
> Cheers,
> uncle rubl
> --
> The more I learn the better I understand I know nothing.
>
>

[-- Attachment #2: Type: text/html, Size: 1780 bytes --]

[TUHS] Re: Clever code

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

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

[TUHS] Re: Clever code

[George Michaelson]

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@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

[TUHS] Re: Clever code

[Ralph Corderoy]

Hi George,

> The "sticky" bit was quite clever. tell the OS to keep something
> memory resident

Was it ever more than a hint?  I've not heard of it locking or pinning
an executable to memory.

> so you can binary patch the back end without worrying.

I think it altered the worrying.  :-)

If not sticky, ‘chmod -x’ the file, ensure no process is running it from
before the chmod, patch, ‘chmod +x’.

If sticky then ‘chmod -tx’, ensure no process is running it from before
the chmod, ‘chmod +x’, run it and exit to remove any stuck copy,
‘chmod -x’, patch, chmod ‘+tx’.

I may have got the detail wrong but avoiding the unpatched copy
lingering in memory is the aim.

-- 
Cheers, Ralph.

[TUHS] Re: Clever code

[Dagobert Michelsen]

Hi Ralph,

> Am 13.12.2022 um 09:05 schrieb Ralph Corderoy <ralph@inputplus.co.uk>:
> 
> Hi George,
> 
>> The "sticky" bit was quite clever. tell the OS to keep something
>> memory resident
> 
> Was it ever more than a hint?  I've not heard of it locking or pinning
> an executable to memory.

Funny thing is that it meant the opposite on Solaris: files with the
sticky bit set avoided the file to go through the page cache and therefore
would never be held in memory. This was e.g. set for swapfiles.
Obviously it is counterproductive to cache stuff in memory which is going
to be swapped out...


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

[TUHS] Re: Clever code

[Ralph Corderoy]

Hi Dave,

> 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) 

I'd have thought the most widespread tale of drum-rotation time is the
wonderful prose version of ‘The Story of Mel’.

-- 
Cheers, Ralph.

[TUHS] Re: Clever code

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

On Tue, 13 Dec 2022, Ralph Corderoy wrote:

> I'd have thought the most widespread tale of drum-rotation time is the 
> wonderful prose version of ‘The Story of Mel’.

Ah yes, a classic!

-- Dave

[TUHS] Re: Clever code

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

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@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

[-- Attachment #2: Type: text/html, Size: 2531 bytes --]

[TUHS] Re: Clever code

[Douglas McIlroy]

Apropos of accessing rotating storage, John Kelly used to describe the
Packard-Bell 250, which had a delay-line memory, as a machine where
addresses refer to time rather than space.

The PB 250 had two instruction-sequencing modes. In one mode, each
instruction included the address of its successor. In the other mode,
whatever popped out the delay line when the current instruction
completed would be executed next.

Doug

On Tue, Dec 13, 2022 at 6:48 AM John P. Linderman <jpl.jpl@gmail.com> wrote:
>
> 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@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

[TUHS] Re: Clever code

[arnold]

Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:

> Apropos of accessing rotating storage, John Kelly used to describe the
> Packard-Bell 250, which had a delay-line memory, as a machine where
> addresses refer to time rather than space.
>
> The PB 250 had two instruction-sequencing modes. In one mode, each
> instruction included the address of its successor. In the other mode,
> whatever popped out the delay line when the current instruction
> completed would be executed next.
>
> Doug

For us (relative) youngsters, can you explain some more how delay
line memory worked? The second mode you describe sounds like it
would be impossible to use if you wanted repeatable, reproducible
runs of your program.

Thanks,

Arnold

[TUHS] Re: Clever code

[Ralph Corderoy]

Hi Arnold,

> > The PB 250 had two instruction-sequencing modes.  In one mode, each
> > instruction included the address of its successor.  In the other
> > mode, whatever popped out the delay line when the current
> > instruction completed would be executed next.
...
> The second mode you describe sounds like it would be impossible to use
> if you wanted repeatable, reproducible runs of your program.

How so?  As long as the time taken by the current instruction was
constant then it would be known what's popping out of the delay line
when it's done.  And if the time varied, say because of an operand or
the need to carry, then that could be used to choose between addresses.
Either way, it's repeatable.

It is as if the PC register on today's CPU was steadily trundling
through program memory in parallel to the execution of the current
instruction and when the fetch cycle started, it got whatever PC was
pointing at.

BTW, there's https://en.wikipedia.org/wiki/Delay-line_memory if you
don't know much about them, though I don't think it covers how the
line's content was modified other than a simple block diagram showing
taps for input and output.
https://en.wikipedia.org/wiki/Delay-line_memory#/media/File:SEACComputer_010.png

-- 
Cheers, Ralph.

[TUHS] Re: Clever code

[Douglas McIlroy]

A delay line is logically like a drum, with circulating data that is
accessible only at one point on the circle. A delay line was
effectively a linear channel along which a train of data pulses was
sent. Pulses received at the far end were reshaped electronically. and
reinjected at the sending end. One kind of delay line was a mercury
column that carried acoustic pulses.. The PB 250 delay line was
magnetostrictive (a technology I know nothing about).

If instruction timing is known, then the next instruction to appear is
predictable. The only caveat is that instruction times should not be
data-dependent. You can lay out sequential code along the circle as
long as no instruction steps on one already placed. When that happens
you must switch modes to jump to an open spot, or perhaps insert nops
to jiggle the layout.

Doug

On Tue, Dec 13, 2022 at 9:31 AM <arnold@skeeve.com> wrote:
>
> Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>
> > Apropos of accessing rotating storage, John Kelly used to describe the
> > Packard-Bell 250, which had a delay-line memory, as a machine where
> > addresses refer to time rather than space.
> >
> > The PB 250 had two instruction-sequencing modes. In one mode, each
> > instruction included the address of its successor. In the other mode,
> > whatever popped out the delay line when the current instruction
> > completed would be executed next.
> >
> > Doug
>
> For us (relative) youngsters, can you explain some more how delay
> line memory worked? The second mode you describe sounds like it
> would be impossible to use if you wanted repeatable, reproducible
> runs of your program.
>
> Thanks,
>
> Arnold

[TUHS] Re: Clever code

[Stuff Received]

On 2022-12-13 10:10, Douglas McIlroy wrote:
> A delay line is logically like a drum, with circulating data that is
> accessible only at one point on the circle. A delay line was
> effectively a linear channel along which a train of data pulses was
> sent. Pulses received at the far end were reshaped electronically. and
> reinjected at the sending end.

I had always thought of a delay line as a precursor to a register (or 
stack) for storing intermediate results.  Is this not an accurate way of 
thinking about it?

N.


> One kind of delay line was a mercury
> column that carried acoustic pulses.. The PB 250 delay line was
> magnetostrictive (a technology I know nothing about).
> 
> If instruction timing is known, then the next instruction to appear is
> predictable. The only caveat is that instruction times should not be
> data-dependent. You can lay out sequential code along the circle as
> long as no instruction steps on one already placed. When that happens
> you must switch modes to jump to an open spot, or perhaps insert nops
> to jiggle the layout.
> 
> Doug
> 
> On Tue, Dec 13, 2022 at 9:31 AM <arnold@skeeve.com> wrote:
>>
>> Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>>
>>> Apropos of accessing rotating storage, John Kelly used to describe the
>>> Packard-Bell 250, which had a delay-line memory, as a machine where
>>> addresses refer to time rather than space.
>>>
>>> The PB 250 had two instruction-sequencing modes. In one mode, each
>>> instruction included the address of its successor. In the other mode,
>>> whatever popped out the delay line when the current instruction
>>> completed would be executed next.
>>>
>>> Doug
>>
>> For us (relative) youngsters, can you explain some more how delay
>> line memory worked? The second mode you describe sounds like it
>> would be impossible to use if you wanted repeatable, reproducible
>> runs of your program.
>>
>> Thanks,
>>
>> Arnold

[TUHS] Re: Clever code

[Ralph Corderoy]

Hi N.,

> I had always thought of a delay line as a precursor to a register (or
> stack) for storing intermediate results.  Is this not an accurate way
> of thinking about it?

As an example, https://en.wikipedia.org/wiki/EDVAC#Technical_description
says

    Physically, the computer comprised the following components:

        - a magnetic tape reader-recorder (Wilkes 1956:36 describes this
          as a wire recorder.)
        ...
        - a dual memory unit consisting of two sets of 64 mercury
          acoustic delay lines of eight words capacity on each line
          [1 Ki words]
        - three temporary delay-line tanks each holding a single word

It looks like the three temporaries were more akin to a stack or
registers with the main delay lines providing working memory distinct
from tape storage.

Another analogy for a delay line might be a steadily turning Rolodex
where the card on display can be read and then written, perhaps with a
different value, before it disappears.

-- 
Cheers, Ralph.

[TUHS] Re: Clever code

[Harald Arnesen]

Douglas McIlroy [13/12/2022 16.10]:

> A delay line is logically like a drum, with circulating data that is
> accessible only at one point on the circle. A delay line was
> effectively a linear channel along which a train of data pulses was
> sent. Pulses received at the far end were reshaped electronically. and
> reinjected at the sending end. One kind of delay line was a mercury
> column that carried acoustic pulses.

And according to Alan Turing, it might have been implemented with Gin 
and Tonic.

[TUHS] Re: Clever code

[arnold]

Thank you for the explanation.  The skill of the programmers who had to
write code for such machines amazes me. I might could have held all
that kind of info in my head when I was younger, but certainly not today...

Thanks,

Arnold

Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:

> A delay line is logically like a drum, with circulating data that is
> accessible only at one point on the circle. A delay line was
> effectively a linear channel along which a train of data pulses was
> sent. Pulses received at the far end were reshaped electronically. and
> reinjected at the sending end. One kind of delay line was a mercury
> column that carried acoustic pulses.. The PB 250 delay line was
> magnetostrictive (a technology I know nothing about).
>
> If instruction timing is known, then the next instruction to appear is
> predictable. The only caveat is that instruction times should not be
> data-dependent. You can lay out sequential code along the circle as
> long as no instruction steps on one already placed. When that happens
> you must switch modes to jump to an open spot, or perhaps insert nops
> to jiggle the layout.
>
> Doug
>
> On Tue, Dec 13, 2022 at 9:31 AM <arnold@skeeve.com> wrote:
> >
> > Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
> >
> > > Apropos of accessing rotating storage, John Kelly used to describe the
> > > Packard-Bell 250, which had a delay-line memory, as a machine where
> > > addresses refer to time rather than space.
> > >
> > > The PB 250 had two instruction-sequencing modes. In one mode, each
> > > instruction included the address of its successor. In the other mode,
> > > whatever popped out the delay line when the current instruction
> > > completed would be executed next.
> > >
> > > Doug
> >
> > For us (relative) youngsters, can you explain some more how delay
> > line memory worked? The second mode you describe sounds like it
> > would be impossible to use if you wanted repeatable, reproducible
> > runs of your program.
> >
> > Thanks,
> >
> > Arnold

[TUHS] Re: Clever code

[Marc Donner]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

Further on delay line storage:

Physically one of the most common ones was a cylinder of liquid mercury.
There was a device at one end for introducing pressure waves into the
mercury (think loudspeaker) and a device at the other end for measuring the
pressure waves arriving (think microphone).  The pulses that came off the
microphone end were then fed back to the loudspeaker end, after being
cleaned up.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Tue, Dec 13, 2022 at 10:12 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> A delay line is logically like a drum, with circulating data that is
> accessible only at one point on the circle. A delay line was
> effectively a linear channel along which a train of data pulses was
> sent. Pulses received at the far end were reshaped electronically. and
> reinjected at the sending end. One kind of delay line was a mercury
> column that carried acoustic pulses.. The PB 250 delay line was
> magnetostrictive (a technology I know nothing about).
>
> If instruction timing is known, then the next instruction to appear is
> predictable. The only caveat is that instruction times should not be
> data-dependent. You can lay out sequential code along the circle as
> long as no instruction steps on one already placed. When that happens
> you must switch modes to jump to an open spot, or perhaps insert nops
> to jiggle the layout.
>
> Doug
>
> On Tue, Dec 13, 2022 at 9:31 AM <arnold@skeeve.com> wrote:
> >
> > Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
> >
> > > Apropos of accessing rotating storage, John Kelly used to describe the
> > > Packard-Bell 250, which had a delay-line memory, as a machine where
> > > addresses refer to time rather than space.
> > >
> > > The PB 250 had two instruction-sequencing modes. In one mode, each
> > > instruction included the address of its successor. In the other mode,
> > > whatever popped out the delay line when the current instruction
> > > completed would be executed next.
> > >
> > > Doug
> >
> > For us (relative) youngsters, can you explain some more how delay
> > line memory worked? The second mode you describe sounds like it
> > would be impossible to use if you wanted repeatable, reproducible
> > runs of your program.
> >
> > Thanks,
> >
> > Arnold
>

[-- Attachment #2: Type: text/html, Size: 3453 bytes --]

[TUHS] Re: Clever code

[Marc Donner]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

Here is a page from the Computer History Museum on the topic:
https://www.computerhistory.org/revolution/memory-storage/8/309

about halfway down the page is a nice schematic.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Thu, Dec 15, 2022 at 1:06 PM Marc Donner <marc.donner@gmail.com> wrote:

> Further on delay line storage:
>
> Physically one of the most common ones was a cylinder of liquid mercury.
> There was a device at one end for introducing pressure waves into the
> mercury (think loudspeaker) and a device at the other end for measuring the
> pressure waves arriving (think microphone).  The pulses that came off the
> microphone end were then fed back to the loudspeaker end, after being
> cleaned up.
> =====
> nygeek.net
> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
>
>
> On Tue, Dec 13, 2022 at 10:12 AM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
>
>> A delay line is logically like a drum, with circulating data that is
>> accessible only at one point on the circle. A delay line was
>> effectively a linear channel along which a train of data pulses was
>> sent. Pulses received at the far end were reshaped electronically. and
>> reinjected at the sending end. One kind of delay line was a mercury
>> column that carried acoustic pulses.. The PB 250 delay line was
>> magnetostrictive (a technology I know nothing about).
>>
>> If instruction timing is known, then the next instruction to appear is
>> predictable. The only caveat is that instruction times should not be
>> data-dependent. You can lay out sequential code along the circle as
>> long as no instruction steps on one already placed. When that happens
>> you must switch modes to jump to an open spot, or perhaps insert nops
>> to jiggle the layout.
>>
>> Doug
>>
>> On Tue, Dec 13, 2022 at 9:31 AM <arnold@skeeve.com> wrote:
>> >
>> > Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>> >
>> > > Apropos of accessing rotating storage, John Kelly used to describe the
>> > > Packard-Bell 250, which had a delay-line memory, as a machine where
>> > > addresses refer to time rather than space.
>> > >
>> > > The PB 250 had two instruction-sequencing modes. In one mode, each
>> > > instruction included the address of its successor. In the other mode,
>> > > whatever popped out the delay line when the current instruction
>> > > completed would be executed next.
>> > >
>> > > Doug
>> >
>> > For us (relative) youngsters, can you explain some more how delay
>> > line memory worked? The second mode you describe sounds like it
>> > would be impossible to use if you wanted repeatable, reproducible
>> > runs of your program.
>> >
>> > Thanks,
>> >
>> > Arnold
>>
>

[-- Attachment #2: Type: text/html, Size: 4593 bytes --]

[TUHS] Delay line memory (was: Clever code)

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Tuesday, 13 December 2022 at  7:31:12 -0700, arnold@skeeve.com wrote:
> For us (relative) youngsters, can you explain some more how delay
> line memory worked?

At a slight tangent, if you're ever in Melbourne (Australia, of
course), you should take a look at CSIRAC, allegedly the oldest intact
computer still in existence.  It had delay line memory.  I took some
photos of it years ago:
http://www.lemis.com/grog/photos/Photos.php?dirdate=20040904

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

[TUHS] Re: Clever code

[Bakul Shah]

On Dec 12, 2022, at 7:30 PM, Rudi Blom <rudi.j.blom@gmail.com> 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.

Similar consideration applied in the early days of unix workstations.
Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec
(17 sectors/track of early ST412/ST506 disks) fast enough. As Warner
said, one dealt with it by formatting the disk so that the logical
blocks N & N+1 (from the OS PoV) were physically more than 1 sector
apart. No clever coding needed!

The "clever" coding we did was to use all 17 sectors rather than 16
+ 1 spare as was intended. Since our first disks were only 5MB in
size, we wanted to use all the space and typical error rate is much
less than 6%. This complicated handling bad blocks and slowed things
down as blocks with soft read errors were copied to blocks at the
very end of the disk. I don't recall whose idea it was but I was the
one who implemented it. I had an especially bad disk for testing on
which I used to build V7 kernels....

> 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.

One has to be careful here as resource constraints change over time.
An optimization for rev N h/w can be a *pessimization* for later revs.
Even if you document code, people tend to leave "working code" alone.

> 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.

Over time comments tend to turn into fake news! Always go to the
primary sources!

[TUHS] Re: Clever code

[Ralph Corderoy]

Hi Bakul,

> Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec
> (17 sectors/track of early ST412/ST506 disks) fast enough.  As Warner
> said, one dealt with it by formatting the disk so that the logical
> blocks N & N+1 (from the OS PoV) were physically more than 1 sector
> apart.

Sticking with ST506 hard drives, by the time the 8 MHz ARM2 from Acorn
was reading a 56 MB Rodime, it was the drive which couldn't keep up so
executables were stored compressed on disk so the CPU had something to
do, uncompressing the sector's content, while it waited for the next
sector to arrive.  :-)

-- 
Cheers, Ralph.

[TUHS] Re: Clever code

[Bakul Shah]

On Dec 13, 2022, at 8:14 AM, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> 
> Hi Bakul,
> 
>> Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec
>> (17 sectors/track of early ST412/ST506 disks) fast enough.  As Warner
>> said, one dealt with it by formatting the disk so that the logical
>> blocks N & N+1 (from the OS PoV) were physically more than 1 sector
>> apart.
> 
> Sticking with ST506 hard drives, by the time the 8 MHz ARM2 from Acorn
> was reading a 56 MB Rodime, it was the drive which couldn't keep up so
> executables were stored compressed on disk so the CPU had something to
> do, uncompressing the sector's content, while it waited for the next
> sector to arrive.  :-)

IIRC the slow part was due to running some common apps! Not much buffering
allowed on a 256KB machine so by the time the app asks for the next block,
on a 1:1 interleave the block would be past the read head and you had to
spend an extra revolution to grab it!

[TUHS] Sector interleaving (was: Clever code)

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Tuesday, 13 December 2022 at  7:52:49 -0800, Bakul Shah wrote:
> On Dec 12, 2022, at 7:30 PM, Rudi Blom <rudi.j.blom@gmail.com> 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.
>
> Similar consideration applied in the early days of unix workstations.
> Fortune 32:16 was a 5.6Mhz machine and couldn't process 1020KB/sec
> (17 sectors/track of early ST412/ST506 disks) fast enough. As Warner
> said, one dealt with it by formatting the disk so that the logical
> blocks N & N+1 (from the OS PoV) were physically more than 1 sector
> apart. No clever coding needed!

CP/M did something similar with floppy disks.  It imposed a 6 fold
software interleave between sectors (logical sectors 1, 2, 3.. were
"physical" sectors 1, 7, 13...)

On soft-sectored floppies, the "physical" sectors were really just the
numbers in the sector header.  By the time I got involved, computers
were far fast enough that they spent a lot of time just waiting for
the next sector.  I wrote a format program that positioned the
"physical" sectors so that there was only one sector between
"physical" 1, 7, 13 and so.  It made an amazing difference to the disk
speed.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

[TUHS] Re: Clever code

[Noel Chiappa]

    > From: Bakul Shah

    > one dealt with it by formatting the disk so that the logical blocks N &
    > N+1 (from the OS PoV) were physically more than 1 sector apart. No
    > clever coding needed!

An old hack. ('Nothing new', and all that.) DEC Rx01/02 floppies used the
same thing, circa 1976.

	Noel

[TUHS] Re: Clever code

[Noel Chiappa]

    > From: Stuff Received

    > I had always thought of a delay line as a precursor to a register (or
    > stack) for storing intermediate results. Is this not an accurate way of
    > thinking about it?

No, not at all.

First: delay lines were a memory _technology_ (one that was inherently
serial, not random-access). They preceded all others.

Second: registers used to have two aspects - one now gone (and maybe the
second too). The first was that the _technology_ used to implement them
(latches built out of tubes, then transistors) was faster than main memory -
a distinction now mostly gone, especially since caches blur the speed
distinction between today's main memory and registers. The second was that
registers, being smaller in numbers, could be named with a few bits, allowing
them to be named with a small share of the bits in an instruction. (This one
still remains, although instructions are now so long it's probably less
important.)

Some delay-line machines had two different delay line sizes (since size is
equivalent to average access time) - what one might consider 'registers' were
kept in the small ones, for fast access at all times, whereas main memory
used the longer ones.

	Noel

[TUHS] Re: Clever code

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

At 2022-12-13T12:58:11-0500, Noel Chiappa wrote:
> ... registers used to have two aspects - one now gone (and maybe
> the second too). The first was that the _technology_ used to implement
> them (latches built out of tubes, then transistors) was faster than
> main memory - a distinction now mostly gone, especially since caches
> blur the speed distinction between today's main memory and registers.
> The second was that registers, being smaller in numbers, could be
> named with a few bits, allowing them to be named with a small share of
> the bits in an instruction. (This one still remains, although
> instructions are now so long it's probably less important.)

Maybe less important on x86, but the amount of space in the instruction
for encoding registers seems to me to have played a major role in the
design of the RV32I/E and C (compressed) extension instruction formats
of RISC-V.

https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Clever code

[segaloco via TUHS]

Where RISC-V is very intentional on this, my reading has lead me to understand that many previous CPU architectures simply passed pieces of the opcode to further hardware in the microarchitecture, so it wasn't so much of a design a register system to fit in a specific bit width but rather a matter of bits 3-5 and 7-9 are connected directly to the two inputs of the ALU internally or something to that effect.  Hearsay of course, I wasn't there, but that's the explanation I've heard in the past.

Now how much settling on a bit width for the register field of opcodes influences the number of registers or vice versa, hard to say.  Did Motorola want a 3 bit register field in opcodes or a resolution of 8 registers per addressing mode in the 68k first for instance, and which decision then followed?  I don't know, maybe someone does?  In fact, that makes me now wonder if there are CPUs with non-power-of-two register counts outside of the early days.  Anything else would waste values in a bitfield.

- Matt G.

------- Original Message -------
On Tuesday, December 13th, 2022 at 10:51 AM, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:


> At 2022-12-13T12:58:11-0500, Noel Chiappa wrote:
> 
> > ... registers used to have two aspects - one now gone (and maybe
> > the second too). The first was that the technology used to implement
> > them (latches built out of tubes, then transistors) was faster than
> > main memory - a distinction now mostly gone, especially since caches
> > blur the speed distinction between today's main memory and registers.
> > The second was that registers, being smaller in numbers, could be
> > named with a few bits, allowing them to be named with a small share of
> > the bits in an instruction. (This one still remains, although
> > instructions are now so long it's probably less important.)
> 
> 
> Maybe less important on x86, but the amount of space in the instruction
> for encoding registers seems to me to have played a major role in the
> design of the RV32I/E and C (compressed) extension instruction formats
> of RISC-V.
> 
> https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
> 
> Regards,
> Branden

[TUHS] Re: Clever code

[Warren Toomey via TUHS]

I think we might move the discussion on memory technologies, CPU 
architectures etc. to COFF 😁

Thanks, Warren

[TUHS] Re: Clever code

[Luther Johnson]

[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]

The CPU I have designed and (implemented, it's running in a Lattice FPGA 
right now)  has three general purpose registers, a frame pointer, and a 
stack pointer. But the encoding problem you mention is real. So instead 
of designing a scheme where the instruction word is split up into 
fields, I have the first byte as the instruction type, and then however 
many immediate data bytes (in this instruction set, 1, or 3) are 
necessary following. The first byte, after it is fetched, is simply fed 
to a lookup table, which then results in a 12 bit value, 6 bits for 
operation, and two 3 bit fields for the a and b registers - these 12 
bits go to the execution stage. This is a two register address, 24 bit 
machine - I designed it as a replacement for the Zilog eZ80, which has 
become hard to get. Anyhow, I get good code density and I've got lots of 
spare codes left. I've attached the ISA description.

I did go through lots of design alternatives to reach the parameters of 
this ISA - they key one was if I wanted to have the operations I needed, 
available across all the general purpose registers, that limited how 
many general purpose registers I could have and keep all the 
enumerations in less than 256 codes, with some to spare. Another set of 
of choices relates to how I wanted to implement C on this machine, and 
that I did not intend for it to support all possible styles of assembly 
language programming - it is meant to support code generated by the C 
compiler, with a minimum of assembly required.

This machine is called "COR24". I can describe the machine in further 
detail, or show you some sample code,  if you're interested.

Luther

On 12/13/2022 01:14 PM, segaloco via TUHS wrote:
> Where RISC-V is very intentional on this, my reading has lead me to understand that many previous CPU architectures simply passed pieces of the opcode to further hardware in the microarchitecture, so it wasn't so much of a design a register system to fit in a specific bit width but rather a matter of bits 3-5 and 7-9 are connected directly to the two inputs of the ALU internally or something to that effect.  Hearsay of course, I wasn't there, but that's the explanation I've heard in the past.
>
> Now how much settling on a bit width for the register field of opcodes influences the number of registers or vice versa, hard to say.  Did Motorola want a 3 bit register field in opcodes or a resolution of 8 registers per addressing mode in the 68k first for instance, and which decision then followed?  I don't know, maybe someone does?  In fact, that makes me now wonder if there are CPUs with non-power-of-two register counts outside of the early days.  Anything else would waste values in a bitfield.
>
> - Matt G.
>
> ------- Original Message -------
> On Tuesday, December 13th, 2022 at 10:51 AM, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
>
>
>> At 2022-12-13T12:58:11-0500, Noel Chiappa wrote:
>>
>>> ... registers used to have two aspects - one now gone (and maybe
>>> the second too). The first was that the technology used to implement
>>> them (latches built out of tubes, then transistors) was faster than
>>> main memory - a distinction now mostly gone, especially since caches
>>> blur the speed distinction between today's main memory and registers.
>>> The second was that registers, being smaller in numbers, could be
>>> named with a few bits, allowing them to be named with a small share of
>>> the bits in an instruction. (This one still remains, although
>>> instructions are now so long it's probably less important.)
>>
>> Maybe less important on x86, but the amount of space in the instruction
>> for encoding registers seems to me to have played a major role in the
>> design of the RV32I/E and C (compressed) extension instruction formats
>> of RISC-V.
>>
>> https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
>>
>> Regards,
>> Branden


[-- Attachment #2: isa.txt --]
[-- Type: text/plain, Size: 14196 bytes --]

Inst    Description             Op      a,b     6+3+3 binary      Hex
----    -----------             --      ---     ---------------   ---
00      add   r0,r0             00      0,0     00 0000 000 000 | 000
01      add   r0,r1             00      0,1     00 0000 000 001 | 001
02      add   r0,r2             00      0,2     00 0000 000 010 | 002
03      add   r1,r0             00      1,0     00 0000 001 000 | 008
04      add   r1,r1             00      1,1     00 0000 001 001 | 009
05      add   r1,r2             00      1,2     00 0000 001 010 | 00a
06      add   r2,r0             00      2,0     00 0000 010 000 | 010
07      add   r2,r1             00      2,1     00 0000 010 001 | 011
08      add   r2,r2             00      2,2     00 0000 010 010 | 012

09      add   r0,dd             01      0,7     00 0001 000 111 | 047
0a      add   r1,dd             01      1,7     00 0001 001 111 | 04f
0b      add   r2,dd             01      2,7     00 0001 010 111 | 057
0c      add   sp,dd             01      4,7     00 0001 100 111 | 067

0d      and   r0,r1             02      0,1     00 0010 000 001 | 081
0e      and   r0,r2             02      0,2     00 0010 000 010 | 082
0f      and   r1,r0             02      1,0     00 0010 001 000 | 088
10      and   r1,r2             02      1,2     00 0010 001 010 | 08a
11      and   r2,r0             02      2,0     00 0010 010 000 | 090
12      and   r2,r1             02      2,1     00 0010 010 001 | 091

13      bra   dd                03      7,7     00 0011 111 111 | 0ff

14      brf   dd                04      7,7     00 0100 111 111 | 13f

15      brt   dd                05      7,7     00 0101 111 111 | 17f

16      ceq   r0,r1             06      0,1     00 0110 000 001 | 181
17      ceq   r0,r2             06      0,2     00 0110 000 010 | 182
18      ceq   r1,r2             06      1,2     00 0110 001 010 | 18a

19      cls   r0,r1             07      0,1     00 0111 000 001 | 1c1
1a      cls   r0,r2             07      0,2     00 0111 000 010 | 1c2
1b      cls   r1,r0             07      1,0     00 0111 001 000 | 1c8
1c      cls   r1,r2             07      1,2     00 0111 001 010 | 1ca
1d      cls   r2,r0             07      2,0     00 0111 010 000 | 1d0
1e      cls   r2,r1             07      2,1     00 0111 010 001 | 1d1

1f      clu   r0,r1             08      0,1     00 1000 000 001 | 201
20      clu   r0,r2             08      0,2     00 1000 000 010 | 202
21      clu   r1,r0             08      1,0     00 1000 001 000 | 208
22      clu   r1,r2             08      1,2     00 1000 001 010 | 20a
23      clu   r2,r0             08      2,0     00 1000 010 000 | 210
24      clu   r2,r1             08      2,1     00 1000 010 001 | 211

25      jal   r1,(r0)           09      1,0     00 1001 001 000 | 248

26      jmp   (r0)              0a      0,7     00 1010 000 111 | 287
27      jmp   (r1)              0a      1,7     00 1010 001 111 | 28f
28      jmp   (r2)              0a      2,7     00 1010 010 111 | 297

29      la    r0,dddddd         0b      0,7     00 1011 000 111 | 2c7
2a      la    r1,dddddd         0b      1,7     00 1011 001 111 | 2cf
2b      la    r2,dddddd         0b      2,7     00 1011 010 111 | 2d7

2c      lb    r0,dd(r0)         0c      0,0     00 1100 000 000 | 300
2d      lb    r0,dd(r1)         0c      0,1     00 1100 000 001 | 301
2e      lb    r0,dd(r2)         0c      0,2     00 1100 000 010 | 302
2f      lb    r0,dd(fp)         0c      0,3     00 1100 000 011 | 303
30      lb    r1,dd(r0)         0c      1,0     00 1100 001 000 | 308
31      lb    r1,dd(r1)         0c      1,1     00 1100 001 001 | 309
32      lb    r1,dd(r2)         0c      1,2     00 1100 001 010 | 30a
33      lb    r1,dd(fp)         0c      1,3     00 1100 001 011 | 30b
34      lb    r2,dd(r0)         0c      2,0     00 1100 010 000 | 310
35      lb    r2,dd(r1)         0c      2,1     00 1100 010 001 | 311
36      lb    r2,dd(r2)         0c      2,2     00 1100 010 010 | 312
37      lb    r2,dd(fp)         0c      2,3     00 1100 010 011 | 313

38      lbu   r0,dd(r0)         0d      0,0     00 1101 000 000 | 340
39      lbu   r0,dd(r1)         0d      0,1     00 1101 000 001 | 341
3a      lbu   r0,dd(r2)         0d      0,2     00 1101 000 010 | 342
3b      lbu   r0,dd(fp)         0d      0,3     00 1101 000 011 | 343
3c      lbu   r1,dd(r0)         0d      1,0     00 1101 001 000 | 348
3d      lbu   r1,dd(r1)         0d      1,1     00 1101 001 001 | 349
3e      lbu   r1,dd(r2)         0d      1,2     00 1101 001 010 | 34a
3f      lbu   r1,dd(fp)         0d      1,3     00 1101 001 011 | 34b
40      lbu   r2,dd(r0)         0d      2,0     00 1101 010 000 | 350
41      lbu   r2,dd(r1)         0d      2,1     00 1101 010 001 | 351
42      lbu   r2,dd(r2)         0d      2,2     00 1101 010 010 | 352
43      lbu   r2,dd(fp)         0d      2,3     00 1101 010 011 | 353

44      lc    r0,dd             0e      0,7     00 1110 000 111 | 387
45      lc    r1,dd             0e      1,7     00 1110 001 111 | 38f
46      lc    r2,dd             0e      2,7     00 1110 010 111 | 397

47      lcu   r0,dd             0f      0,7     00 1111 000 111 | 3c7
48      lcu   r1,dd             0f      1,7     00 1111 001 111 | 3cf
49      lcu   r2,dd             0f      2,7     00 1111 010 111 | 3d7

4a      lw    r0,dd(r0)         10      0,0     01 0000 000 000 | 400
4b      lw    r0,dd(r1)         10      0,1     01 0000 000 001 | 401
4c      lw    r0,dd(r2)         10      0,2     01 0000 000 010 | 402
4d      lw    r0,dd(fp)         10      0,3     01 0000 000 011 | 403
4e      lw    r1,dd(r0)         10      1,0     01 0000 001 000 | 408
4f      lw    r1,dd(r1)         10      1,1     01 0000 001 001 | 409
50      lw    r1,dd(r2)         10      1,2     01 0000 001 010 | 40a
51      lw    r1,dd(fp)         10      1,3     01 0000 001 011 | 40b
52      lw    r2,dd(r0)         10      2,0     01 0000 010 000 | 410
53      lw    r2,dd(r1)         10      2,1     01 0000 010 001 | 411
54      lw    r2,dd(r2)         10      2,2     01 0000 010 010 | 412
55      lw    r2,dd(fp)         10      2,3     01 0000 010 011 | 413

56      mov   r0,r1             11      0,1     01 0001 000 001 | 441
57      mov   r0,r2             11      0,2     01 0001 000 010 | 442
58      mov   r0,fp             11      0,3     01 0001 000 011 | 443
59      mov   r0,sp             11      0,4     01 0001 000 100 | 444
5a      mov   r1,r0             11      1,0     01 0001 001 000 | 448
5b      mov   r1,r2             11      1,2     01 0001 001 010 | 44a
5c      mov   r1,fp             11      1,3     01 0001 001 011 | 44b
5d      mov   r1,sp             11      1,4     01 0001 001 100 | 44c
5e      mov   r2,r0             11      2,0     01 0001 010 000 | 450
5f      mov   r2,r1             11      2,1     01 0001 010 001 | 451
60      mov   r2,fp             11      2,3     01 0001 010 011 | 453
61      mov   r2,sp             11      2,4     01 0001 010 100 | 454
62      mov   r0,c              11      0,5     01 0001 000 101 | 445
63      mov   r1,c              11      1,5     01 0001 001 101 | 44d
64      mov   r2,c              11      2,5     01 0001 010 101 | 455
65      mov   fp,sp             11      3,4     01 0001 011 100 | 45c
66      mov   sp,r0             11      4,0     01 0001 100 000 | 460
67      mov   sp,r1             11      4,1     01 0001 100 001 | 461
68      mov   sp,r2             11      4,2     01 0001 100 010 | 462
69      mov   sp,fp             11      4,3     01 0001 100 011 | 463

6a      mul   r0,r0             12      0,0     01 0010 000 000 | 480
6b      mul   r0,r1             12      0,1     01 0010 000 001 | 481
6c      mul   r0,r2             12      0,2     01 0010 000 010 | 482
6d      mul   r1,r0             12      1,0     01 0010 001 000 | 488
6e      mul   r1,r1             12      1,1     01 0010 001 001 | 489
6f      mul   r1,r2             12      1,2     01 0010 001 010 | 48a
70      mul   r2,r0             12      2,0     01 0010 010 000 | 490
71      mul   r2,r1             12      2,1     01 0010 010 001 | 491
72      mul   r2,r2             12      2,2     01 0010 010 010 | 492

73      or    r0,r1             13      0,1     01 0011 000 001 | 4c1
74      or    r0,r2             13      0,2     01 0011 000 010 | 4c2
75      or    r1,r0             13      1,0     01 0011 001 000 | 4c8
76      or    r1,r2             13      1,2     01 0011 001 010 | 4ca
77      or    r2,r0             13      2,0     01 0011 010 000 | 4d0
78      or    r2,r1             13      2,1     01 0011 010 001 | 4d1

79      pop     r0              14      0,4     01 0100 000 100 | 504
7a      pop     r1              14      1,4     01 0100 001 100 | 50c
7b      pop     r2              14      2,4     01 0100 010 100 | 514
7c      pop     fp              14      3,4     01 0100 011 100 | 51c

7d      push    r0              15      0,4     01 0101 000 100 | 544
7e      push    r1              15      1,4     01 0101 001 100 | 54c
7f      push    r2              15      2,4     01 0101 010 100 | 554
80      push    fp              15      3,4     01 0101 011 100 | 55c

81      sb    r0,dd(r1)         16      0,1     01 0110 000 001 | 581
82      sb    r0,dd(r2)         16      0,2     01 0110 000 010 | 582
83      sb    r0,dd(fp)         16      0,3     01 0110 000 011 | 583
84      sb    r1,dd(r0)         16      1,0     01 0110 001 000 | 588
85      sb    r1,dd(r2)         16      1,2     01 0110 001 010 | 58a
86      sb    r1,dd(fp)         16      1,3     01 0110 001 011 | 58b
87      sb    r2,dd(r0)         16      2,0     01 0110 010 000 | 590
88      sb    r2,dd(r1)         16      2,1     01 0110 010 001 | 591
89      sb    r2,dd(fp)         16      2,3     01 0110 010 011 | 593

8a      shl   r0,r1             17      0,1     01 0111 000 001 | 5c1
8b      shl   r0,r2             17      0,2     01 0111 000 010 | 5c2
8c      shl   r1,r0             17      1,0     01 0111 001 000 | 5c8
8d      shl   r1,r2             17      1,2     01 0111 001 010 | 5ca
8e      shl   r2,r0             17      2,0     01 0111 010 000 | 5d0
8f      shl   r2,r1             17      2,1     01 0111 010 001 | 5d1

90      sra   r0,r1             18      0,1     01 1000 000 001 | 601
91      sra   r0,r2             18      0,2     01 1000 000 010 | 602
92      sra   r1,r0             18      1,0     01 1000 001 000 | 608
93      sra   r1,r2             18      1,2     01 1000 001 010 | 60a
94      sra   r2,r0             18      2,0     01 1000 010 000 | 610
95      sra   r2,r1             18      2,1     01 1000 010 001 | 611

96      srl   r0,r1             19      0,1     01 1001 000 001 | 641
97      srl   r0,r2             19      0,2     01 1001 000 010 | 642
98      srl   r1,r0             19      1,0     01 1001 001 000 | 648
99      srl   r1,r2             19      1,2     01 1001 001 010 | 64a
9a      srl   r2,r0             19      2,0     01 1001 010 000 | 650
9b      srl   r2,r1             19      2,1     01 1001 010 001 | 651

9c      sub   r0,r1             1a      0,1     01 1010 000 001 | 681
9d      sub   r0,r2             1a      0,2     01 1010 000 010 | 682
9e      sub   r1,r0             1a      1,0     01 1010 001 000 | 688
9f      sub   r1,r2             1a      1,2     01 1010 001 010 | 68a
a0      sub   r2,r0             1a      2,0     01 1010 010 000 | 690
a1      sub   r2,r1             1a      2,1     01 1010 010 001 | 691

a2      sub   sp,dddddd         1b      4,7     01 1011 100 111 | 6e7

a3      sw    r0,dd(r0)         1c      0,0     01 1100 000 000 | 700
a4      sw    r0,dd(r1)         1c      0,1     01 1100 000 001 | 701
a5      sw    r0,dd(r2)         1c      0,2     01 1100 000 010 | 702
a6      sw    r0,dd(fp)         1c      0,3     01 1100 000 011 | 703
a7      sw    r1,dd(r0)         1c      1,0     01 1100 001 000 | 708
a8      sw    r1,dd(r1)         1c      1,1     01 1100 001 001 | 709
a9      sw    r1,dd(r2)         1c      1,2     01 1100 001 010 | 70a
aa      sw    r1,dd(fp)         1c      1,3     01 1100 001 011 | 70b
ab      sw    r2,dd(r0)         1c      2,0     01 1100 010 000 | 710
ac      sw    r2,dd(r1)         1c      2,1     01 1100 010 001 | 711
ad      sw    r2,dd(r2)         1c      2,2     01 1100 010 010 | 712
ae      sw    r2,dd(fp)         1c      2,3     01 1100 010 011 | 713

af      sxt   r0,r0             1d      0,0     01 1101 000 000 | 740
b0      sxt   r0,r1             1d      0,1     01 1101 000 001 | 741
b1      sxt   r0,r2             1d      0,2     01 1101 000 010 | 742
b2      sxt   r1,r0             1d      1,0     01 1101 001 000 | 748
b3      sxt   r1,r1             1d      1,1     01 1101 001 001 | 749
b4      sxt   r1,r2             1d      1,2     01 1101 001 010 | 74a
b5      sxt   r2,r0             1d      2,0     01 1101 010 000 | 750
b6      sxt   r2,r1             1d      2,1     01 1101 010 001 | 751
b7      sxt   r2,r2             1d      2,1     01 1101 010 010 | 752

b8      xor   r0,r1             1e      0,1     01 1110 000 001 | 781
b9      xor   r0,r2             1e      0,2     01 1110 000 010 | 782
ba      xor   r1,r0             1e      1,0     01 1110 001 000 | 788
bb      xor   r1,r2             1e      1,2     01 1110 001 010 | 78a
bc      xor   r2,r0             1e      2,0     01 1110 010 000 | 790
bd      xor   r2,r1             1e      2,1     01 1110 010 001 | 791

be      zxt   r0,r0             1f      0,0     01 1111 000 000 | 7c0
bf      zxt   r0,r1             1f      0,1     01 1111 000 001 | 7c1
c0      zxt   r0,r2             1f      0,2     01 1111 000 010 | 7c2
c1      zxt   r1,r0             1f      1,0     01 1111 001 000 | 7c8
c2      zxt   r1,r1             1f      1,1     01 1111 001 001 | 7c9
c3      zxt   r1,r2             1f      1,2     01 1111 001 010 | 7ca
c4      zxt   r2,r0             1f      2,0     01 1111 010 000 | 7d0
c5      zxt   r2,r1             1f      2,1     01 1111 010 001 | 7d1
c6      zxt   r2,r2             1f      2,2     01 1111 010 010 | 7d2

=== Late additions ===

c7      jmp   dddddd            0b      7,7     00 1011 111 111 | 2ff

[TUHS] Re: Stdin Redirect in Cu History/Alternatives?

[Larry McVoy]

On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote:
> On Sun, 11 Dec 2022, Michael Kj??rling wrote:
> 
> > By definition, if you write code as cleverly as you can, then you aren't 
> > clever enough to debug it...
> 
> Indeed...
> 
> I've always used the maxim "Write code as though the next person to 
> maintain it is an axe-wielding psychopath who knows where you live".

My main job, for the 20 years until I retired, was to keep telling 
people that code that you wrote 6 months ago might as well have been
written by someone else.  Optimize for reading the code, not writing
the code.  It's read many.

99.9% of the time, I detest clever code.  .1% of the time, I need it.
The problem is that smart engineers adore writing clever code.  They
usually, eventually, wise up.

[TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives?

[Bakul Shah]

On Dec 11, 2022, at 12:04 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> 
> 
> On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote:
>> On Sun, 11 Dec 2022, Michael Kj??rling wrote:
>> 
>>> By definition, if you write code as cleverly as you can, then you aren't 
>>> clever enough to debug it...
>> 
>> Indeed...
>> 
>> I've always used the maxim "Write code as though the next person to 
>> maintain it is an axe-wielding psychopath who knows where you live".
> 
> My main job, for the 20 years until I retired, was to keep telling 
> people that code that you wrote 6 months ago might as well have been
> written by someone else.  Optimize for reading the code, not writing
> the code.  It's read many.
> 
> 99.9% of the time, I detest clever code.  .1% of the time, I need it.
> The problem is that smart engineers adore writing clever code.  They
> usually, eventually, wise up.

Agree that clear code is preferable to complicated code. But in practice
people sacrifice clarity for performance improvement all the time. Look
at the kernel code of any modern os. Everybody pays lip service to this
but most anything other than toy programs ends up getting needlessly
complicated over time. As an example, building "Unix as a service" as
user processes on top of a small microkernel could provide the same
functionality using much clearer and much less code but it would be
slower so we don't do it. Plan9 sort of went in that direction and it
is much simpler (but that could also be because it is not hacked on so
much).

I do prefer clever/smart design to locally clever/smart code. For example,
using Schönhage-Strassen algorithm for multiplying very large numbers.
Or transforming a problem to use a much more efficient data structure
or making equivalent transforms which may be more efficient to compute.
Such code may not be immediately clear but with proper documentation
it is not difficult + you can solve much larger problems. But agreed
these come up much less often. 

[TUHS] Re: Clever code

[Michael Kjörling]

On 11 Dec 2022 18:15 -0800, from bakul@iitbombay.org (Bakul Shah):
> Agree that clear code is preferable to complicated code. But in practice
> people sacrifice clarity for performance improvement all the time. Look
> at the kernel code of any modern os. Everybody pays lip service to this
> but most anything other than toy programs ends up getting needlessly
> complicated over time.

Performant code does not need to stand in opposition to clear code.
And if you are writing performance-critical or size-critical code
(such as the QNX microkernel that someone brought up), then of course
you might end up needing to do things in non-obvious ways; that's not
the point here. Clever is fine IMO _where the cleverness provides an
actual benefit in a real-world scenario_, and an operating system
kernel (and a language standard library) is a rather special type of
program where sometimes you have to do things in somewhat non-obvious
ways because of the environment the code is meant to execute in. But a
significant portion of the time, where I see "clever" code there is
_no_ significant benefit to the cleverness; it's often more about
"showing off", or saving a few source code characters at the expense
of at-a-glance readability, than it is about actual usefulness and
necessity.

Necessary complexity in order to solve the problem, combined with
things like performance requirements, may sometimes require clever
code. At that point, there is a benefit to the cleverness. But one can
still aim to write the clever code _clearly_, with everything from
comments to good variable and function names to formatting that
enhances readability by for example grouping related operations
together in the source code to keeping related parts grouped together
and separate from other code. Just such a simple thing as that I often
add extra parenthesis over and beyond what's actually required based
on operator precedence, because doing so makes it clearer what goes
together and unless the compiler is severely braindead by modern
standards, doing so costs _nothing_ past the compilation stage.

-- 
✍  Michael Kjörling                  🏡 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”