[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 --]