13 Dec
2022
13 Dec
'22
3:30 a.m.
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.
13 Dec
13 Dec
3:41 a.m.
New subject: Clever code
On Mon, Dec 12, 2022, 8:32 PM Rudi Blom <rudi.j.blom(a)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.
3:53 a.m.
New subject: Clever code
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
4:03 a.m.
New subject: Clever code
The "sticky" bit was quite clever. tell the OS to keep something
memory resident, so you can binary patch the back end without
worrying.
Copy on Write was enormously clever. Keeping FD open across fork/exec
was fantastically clever.
making a null pointer be a valid address was probably not clever
(PDP11) but I expect somebody will explain to me why it was clever.
On Tue, Dec 13, 2022 at 1:53 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 13 Dec 2022, Rudi Blom wrote:
I vaguely remember having read here about
'clever code' which took into
account the time a magnetic drum needed to rotate in order to optimise
access.
Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program)
on the IBM 650; the programmer wrote the code "straight down" and SOAP
reordered it for rotational latency.
Similarly I can imagine that with resource
restraints you sometimes need to
be clever in order to get your program to fit. Of course, any such
cleverness needs extra documentation.
Try writing a bootstrap program in 512 bytes :-) Self-modifying code was
the order of the day...
I only ever programmed in user space but even
then without lots of comment
in my code I may already start wondering what I did after only a few months
past.
You could be clever in kernel space too, such as taking advantage of
the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e.
read/modify/write.
-- Dave 
8:05 a.m.
New subject: Clever code
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.
9:45 a.m.
New subject: Clever code
Hi Ralph,
Am 13.12.2022 um 09:05 schrieb Ralph Corderoy
<ralph(a)inputplus.co.uk>:
Hi George,
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
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.
7:47 a.m.
New subject: Clever code
Hi Dave,
Rudi Blom wrote:
I'd have thought the most widespread tale of drum-rotation time is the
wonderful prose version of ‘The Story of Mel’.
--
Cheers, Ralph.
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)
11:46 a.m.
New subject: Clever code
There was a story that old hands would torment newcomers to the IBM 650
by tinkering with the optimizer to make it as slow as possible (and, with
rotating drums, that could be VERY slow). Then they'd look at the
newcomer's code, make a trivial change, run it with the real optimizer,
and get dazzling improvements.
I also recall punched card bootstrap programs for the IBM 7094 that
would load column binary when run column binary, and load row binary
when run row binary. -- jpl
On Mon, Dec 12, 2022 at 10:53 PM Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 13 Dec 2022, Rudi Blom wrote:
I vaguely remember having read here about
'clever code' which took into
account the time a magnetic drum needed to rotate in order to optimise
access.
Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program)
on the IBM 650; the programmer wrote the code "straight down" and SOAP
reordered it for rotational latency.
Similarly I can imagine that with resource
restraints you sometimes need
to
be clever in order to get your program to fit. Of
course, any such
cleverness needs extra documentation.
Try writing a bootstrap program in 512 bytes :-) Self-modifying code was
the order of the day...
I only ever programmed in user space but even
then without lots of
comment
in my code I may already start wondering what I
did after only a few
months
past.
You could be clever in kernel space too, such as taking advantage of
the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e.
read/modify/write.
-- Dave 
2:07 p.m.
New subject: Clever code
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(a)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(a)horsfall.org> wrote:
>
> On Tue, 13 Dec 2022, Rudi Blom wrote:
>
> > I vaguely remember having read here about 'clever code' which took
into
> > account the time a magnetic drum needed to rotate in order to optimise
> > access.
>
> Sounds like you're referring to SOAP (Symbolic Optimal Assembly Program)
> on the IBM 650; the programmer wrote the code "straight down" and SOAP
> reordered it for rotational latency.
>
> > Similarly I can imagine that with resource restraints you sometimes need to
> > be clever in order to get your program to fit. Of course, any such
> > cleverness needs extra documentation.
>
> Try writing a bootstrap program in 512 bytes :-) Self-modifying code was
> the order of the day...
>
> > I only ever programmed in user space but even then without lots of comment
> > in my code I may already start wondering what I did after only a few months
> > past.
>
> You could be clever in kernel space too, such as taking advantage of
> the DATIP/DATO cycles on DEC's Unibus when updating a memory word i.e.
> read/modify/write.
>
> -- Dave
2:31 p.m.
New subject: Clever code
Douglas McIlroy <douglas.mcilroy(a)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
2:48 p.m.
New subject: Clever code
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_01…
--
Cheers, Ralph.
3:10 p.m.
New subject: Clever code
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(a)skeeve.com> wrote:
Douglas McIlroy <douglas.mcilroy(a)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 
3:34 p.m.
New subject: Clever code
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(a)skeeve.com> wrote:
>
> Douglas McIlroy <douglas.mcilroy(a)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
3:56 p.m.
New subject: Clever code
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.
11:02 p.m.
New subject: Clever code
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.
14 Dec
14 Dec
7:31 a.m.
New subject: Clever code
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(a)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(a)skeeve.com> wrote:
>
> Douglas McIlroy <douglas.mcilroy(a)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
15 Dec
15 Dec
6:06 p.m.
New subject: Clever code
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(a)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(a)skeeve.com> wrote:
Douglas McIlroy <douglas.mcilroy(a)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
6:08 p.m.
New subject: Clever code
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(a)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(a)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(a)skeeve.com> wrote:
Douglas McIlroy <douglas.mcilroy(a)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 
6:30 a.m.
New subject: Delay line memory (was: Clever code)
On Tuesday, 13 December 2022 at 7:31:12 -0700, arnold(a)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(a)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
13 Dec
13 Dec
3:52 p.m.
New subject: Clever code
On Dec 12, 2022, at 7:30 PM, Rudi Blom <rudi.j.blom(a)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!
4:14 p.m.
New subject: Clever code
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.
4:30 p.m.
New subject: Clever code
On Dec 13, 2022, at 8:14 AM, Ralph Corderoy <ralph(a)inputplus.co.uk> wrote:
Hi Bakul,
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!
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. :-)
15 Dec
15 Dec
6:39 a.m.
New subject: Sector interleaving (was: Clever code)
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(a)gmail.com> wrote:
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(a)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
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!
787
days inactive
789
days old
23 comments
14 participants
participants (14)
-
arnold＠skeeve.com -
Bakul Shah -
Dagobert Michelsen -
Dave Horsfall -
Douglas McIlroy -
George Michaelson -
Greg 'groggy' Lehey -
Harald Arnesen -
John P. Linderman -
Marc Donner -
Ralph Corderoy -
Rudi Blom -
Stuff Received -
Warner Losh