After trying to work out all kinds of bizarre ways to make a computer
that uses a 12-bit basic unit of memory work efficiently with
single-precision floats that are 36 bits long, and double-precision
floats that are 60 bits long, I've decided it's time to throw in the towel
on that one, and achieve my goals in another way.

http://www.quadibloc.com/arch/per15.htm

Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.

That double-precision numbers are 72 bits long now can be dealt
with by taking inspiration from the Cray I computer. If I really want 60 bit
floats, or decide not to be too bold, and settle for 64 bit floats, I can
still keep essentially the same speed of computation by taking all the
extra bits obtained by going to 72 bits, and giving all of them to the
exponent without lengthening the mantissa at all!

That keeps life very simple, and allows the computer to operate in a simple
and efficient manner.

John Savard

On 9/11/2023 10:32 PM, Quadibloc wrote:
> After trying to work out all kinds of bizarre ways to make a computer
> that uses a 12-bit basic unit of memory work efficiently with
> single-precision floats that are 36 bits long, and double-precision
> floats that are 60 bits long, I've decided it's time to throw in the towel
> on that one, and achieve my goals in another way.
>
> http://www.quadibloc.com/arch/per15.htm
>
> Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
>
> That double-precision numbers are 72 bits long

Congratulations! You have reinvented the Univac 1108! :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
> After trying to work out all kinds of bizarre ways to make a computer
> that uses a 12-bit basic unit of memory work efficiently with
> single-precision floats that are 36 bits long, and double-precision
> floats that are 60 bits long, I've decided it's time to throw in the towel
> on that one, and achieve my goals in another way.
<
Oh, BTW, CDC 6600 60-bit FP was considered single precision.......
>
> http://www.quadibloc.com/arch/per15.htm
>
> Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
<
Well that only took 2 years longer than it should have.
>
> That double-precision numbers are 72 bits long now can be dealt
> with by taking inspiration from the Cray I computer. If I really want 60 bit
> floats, or decide not to be too bold, and settle for 64 bit floats, I can
> still keep essentially the same speed of computation by taking all the
> extra bits obtained by going to 72 bits, and giving all of them to the
> exponent without lengthening the mantissa at all!
>
> That keeps life very simple, and allows the computer to operate in a simple
> and efficient manner.
>
> John Savard

On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
> On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
> > After trying to work out all kinds of bizarre ways to make a computer
> > that uses a 12-bit basic unit of memory work efficiently with
> > single-precision floats that are 36 bits long, and double-precision
> > floats that are 60 bits long, I've decided it's time to throw in the towel
> > on that one, and achieve my goals in another way.
> <
> Oh, BTW, CDC 6600 60-bit FP was considered single precision.......

Yes, because the CDC 6600 had a 60-bit word length.

Since it was a big powerful computer dedicated to scientific
computing, that its single precision was almost as long as the
double precision of ordinary computers primarily dedicated to
mundane tasks...

well, that made it seem to me that since its 60-bit numbers did
the same job as the 64-bit numbers on other computers, it was
appropriate for me to think of it as a floating-point format suitable
for double-precision tasks on other computers.

The 6600 may have had 120-bit double precision, but I am also
presuming it wasn't used much.

John Savard

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, September 12, 2023 at 12:32:41=E2=80=AFAM UTC-5, Quadibloc wrot=
>e:
>> After trying to work out all kinds of bizarre ways to make a computer=20
>> that uses a 12-bit basic unit of memory work efficiently with=20
>> single-precision floats that are 36 bits long, and double-precision=20
>> floats that are 60 bits long, I've decided it's time to throw in the towe=
>l=20
>> on that one, and achieve my goals in another way.=20
><
>Oh, BTW, CDC 6600 60-bit FP was considered single precision.......

As was the 400-bit decimal FP on the Burroughs B3500.

(100 digit mantissa, 2 digit exponent).

On Tuesday, September 12, 2023 at 3:41:56 PM UTC-5, Quadibloc wrote:
> On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
> > On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
> > > After trying to work out all kinds of bizarre ways to make a computer
> > > that uses a 12-bit basic unit of memory work efficiently with
> > > single-precision floats that are 36 bits long, and double-precision
> > > floats that are 60 bits long, I've decided it's time to throw in the towel
> > > on that one, and achieve my goals in another way.
> > <
> > Oh, BTW, CDC 6600 60-bit FP was considered single precision.......
> Yes, because the CDC 6600 had a 60-bit word length.
>
> Since it was a big powerful computer dedicated to scientific
> computing, that its single precision was almost as long as the
> double precision of ordinary computers primarily dedicated to
> mundane tasks...
>
> well, that made it seem to me that since its 60-bit numbers did
> the same job as the 64-bit numbers on other computers, it was
> appropriate for me to think of it as a floating-point format suitable
> for double-precision tasks on other computers.
>
> The 6600 may have had 120-bit double precision, but I am also
> presuming it wasn't used much.
<
The ISA allowed for construction of 120-bit FP calculations taking
several instructions.
>
> John Savard

On Tuesday, September 12, 2023 at 3:42:38 PM UTC-6, MitchAlsup wrote:

> The ISA allowed for construction of 120-bit FP calculations taking
> several instructions.

Ah. This is similar to the IBM 704, then, which only had hardware
floating-point instructions for 36-bit single precision, but those
instructions left extra data in the registers which allowed double-precision
numbers built from two floating-point numbers to be used in computation
by using multiple instructions for the basic operations.

John Savard

On Tuesday, September 12, 2023 at 8:23:31 PM UTC-5, Quadibloc wrote:
> On Tuesday, September 12, 2023 at 3:42:38 PM UTC-6, MitchAlsup wrote:
>
> > The ISA allowed for construction of 120-bit FP calculations taking
> > several instructions.
<
> Ah. This is similar to the IBM 704, then, which only had hardware
> floating-point instructions for 36-bit single precision, but those
> instructions left extra data in the registers which allowed double-precision
> numbers built from two floating-point numbers to be used in computation
> by using multiple instructions for the basic operations.
<
It was not two 60-bit FP numbers, but one 60-bit FP number and one 60-bit
integer tacked on the LOB positions--the pair sharing the ~15-bit exponent.
<
>
> John Savard

In article <939d8105-a461-4a09-928e-b7f78248793fn@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> well, that made it seem to me that since its 60-bit numbers did
> the same job as the 64-bit numbers on other computers, it was
> appropriate for me to think of it as a floating-point format
> suitable for double-precision tasks on other computers.

Many of them, sure. But not all. The modeller I work on was designed to
the safe limits for both VAX and IEEE 64-bit, and would hit trouble on
your formats. I don't worry about this.

John

On Tuesday, September 12, 2023 at 7:35:37 PM UTC-6, MitchAlsup wrote:

> It was not two 60-bit FP numbers, but one 60-bit FP number and one 60-bit
> integer tacked on the LOB positions--the pair sharing the ~15-bit exponent.

I just checked the 6600 Computer System Reference Manual, and I found that
opcode 32 is Floating DP Sum of Xj and Xk to Xi, described as follows:

This instruction forms the sum of two floating point numbers as in the floating
sum (30) instruction, but packs the _lower half_ of the double precision sum
with an exponent 48 less than the upper sum.

So apparently it does handle double precision in much the same way as the
704 after all.

John Savard

On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
> On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:

> > Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.

> Well that only took 2 years longer than it should have.

A number of the solutions I proposed to using variables of odd lengths
would work with reasonable efficiency, such as using a 12-bit unit and
simply using standard techniques for supporting access of unaligned
operands in memory - basically, use dual-channel memory, and everything
works just fine, with only a small overhead.

But I wasn't satisfied since my goal is a blazingly-fast vector architecture,
like the Cray I or the NEC SX-Aurora TSUBASA, its current spiritual successor,
and so I wanted the ultimate in speed, with almost no overhead resulting from
unusual memory widths.

I think you need to sing along with me...

The world will be better for this,
That one man, scorned and covered with scars,
Still strove, with his last ounce of courage

John Savard

On Monday, September 11, 2023 at 11:52:32 PM UTC-6, Stephen Fuld wrote:

> Congratulations! You have reinvented the Univac 1108! :-)

Well, not quite. The Univac 36-bit machines were resolutely confined to using
6-bit characters, with no support for lower-case. So a machine that instead
imitates the IBM 360, with byte addressing, but a 9-bit byte, is still different
from the Univac 1108 in some important respects.

John Savard

On Wednesday, September 13, 2023 at 9:02:45 AM UTC-5, Quadibloc wrote:
> On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
> > On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
>
> > > Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
>
> > Well that only took 2 years longer than it should have.
<
> A number of the solutions I proposed to using variables of odd lengths
> would work with reasonable efficiency, such as using a 12-bit unit and
> simply using standard techniques for supporting access of unaligned
> operands in memory - basically, use dual-channel memory, and everything
> works just fine, with only a small overhead.
>
> But I wasn't satisfied since my goal is a blazingly-fast vector architecture,
<
I should note: almost all computers known in their day as being blazingly fast
were extremely simple......
<
> like the Cray I or the NEC SX-Aurora TSUBASA, its current spiritual successor,
> and so I wanted the ultimate in speed, with almost no overhead resulting from
> unusual memory widths.
<
These machines were designed to exploit cacheless multi-banked memory systems
with 4-64× the BW of a "mainframe" of that same time period.
>
> I think you need to sing along with me...
>
> The world will be better for this,
> That one man, scorned and covered with scars,
> Still strove, with his last ounce of courage
to be crucified.....
>
> John Savard

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Monday, September 11, 2023 at 11:52:32 PM UTC-6, Stephen Fuld wrote:
>
>> Congratulations! You have reinvented the Univac 1108! :-)
>
>Well, not quite. The Univac 36-bit machines were resolutely confined to using
>6-bit characters, with no support for lower-case. So a machine that instead
>imitates the IBM 360, with byte addressing, but a 9-bit byte, is still different
>from the Univac 1108 in some important respects.

Sounds more like the GE 635 which had tally pointers that could reference either
six or nine bit characters.

You could use nine bit bytes on the PDP-6 and -10 since you could use any byte
size from 1 to 36, but in practice it was all seven bit ASCII.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 9/13/2023 7:10 AM, Quadibloc wrote:
> On Monday, September 11, 2023 at 11:52:32 PM UTC-6, Stephen Fuld wrote:
>
>> Congratulations! You have reinvented the Univac 1108! :-)
>
> Well, not quite. The Univac 36-bit machines were resolutely confined to using
> 6-bit characters, with no support for lower-case.

Not true! Early in the 1108 production, Univac added a (user settable)
bit in the Processor Status Register that, when set, caused four of the
partial word designator values to be redefined as "quarter words", i.e 9
bits. In this mode, and with the appropriate compilers, etc., there was
full application support for ASCII, including lower case. However,
since most of the OS used six bit characters (Fieldata), things like
file names were restricted to upper case only. But applications could
use either, and there were multiple versions of the compilers during the
transition.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 9/13/2023 10:43 AM, MitchAlsup wrote:
> On Wednesday, September 13, 2023 at 9:02:45 AM UTC-5, Quadibloc wrote:
>> On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
>>> On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
>>
>>>> Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
>>
>>> Well that only took 2 years longer than it should have.
> <
>> A number of the solutions I proposed to using variables of odd lengths
>> would work with reasonable efficiency, such as using a 12-bit unit and
>> simply using standard techniques for supporting access of unaligned
>> operands in memory - basically, use dual-channel memory, and everything
>> works just fine, with only a small overhead.
>>
>> But I wasn't satisfied since my goal is a blazingly-fast vector architecture,
> <
> I should note: almost all computers known in their day as being blazingly fast
> were extremely simple......
> <

Yeah.

Early on, maximizing clock speed seemed to be the ideal.
More MHz, more instructions per second, more fast.
The "More MHz" part being achieved by minimizing unnecessary logic.

But, when there is an upper limit to MHz, it may become more practical
not to try to build a race car, and instead build a dump-truck.

Like, the race-car might be able to drive around faster, but the
dump-truck can haul far more than the race-car could ever hope to manage.

>> like the Cray I or the NEC SX-Aurora TSUBASA, its current spiritual successor,
>> and so I wanted the ultimate in speed, with almost no overhead resulting from
>> unusual memory widths.
> <
> These machines were designed to exploit cacheless multi-banked memory systems
> with 4-64× the BW of a "mainframe" of that same time period.

Now we have RAM modules with power-of-2 sizes for everything.
Bus width: Power of 2 (typically 16-bits on the HW I have access to);
Burst size: Power of 2 (typically 8x 16-bits);
Row size: Power of 2;
Row count: Also power of 2.

No good way to throw any non-power-of-2 sizes in there without shooting
oneself in the foot in the process.

And, even if one did, no standard software could be "easily" ported to
it (since all of the software tends to assume a set of well-known
power-of-2 sizes for each type, among other things...).

Like, porting is already enough of a pain when one typically needs to
rewrite parts of the code to deal with a non-standard OS and build
setup, vs just being able to be like "./configure --target=whatever ...".

But, still haven't gone up the curve of getting BGBCC to be a sufficient
substitute for GCC/binutils to be able to get 'configure' and friends to
play along with it (when I had started working on TKuCC, a sub-goal was
to try to make it more closely mimic GCC/binutils commands and
command-line arguments, *).

*: By contrast, BGBCC was originally written to accept command-lines
more like those given to MSVC, which are significantly different.
So, for example, it needs to provide *-as/ *-ar / *-cc / etc, with
similar behavior to that provided by GCC. Formats are slightly more
flexible, but still need to have .o / .a / ... file extensions.

So, for example, had ended up going for a non-standard "WOFF"
object-format, rather than COFF or ELF, where in this case a "WOFF" if
basically a modified version of the "WAD2" file format posing as an
object module... This, in part, because "just throw the sections into a
WAD" seemed like less effort than dealing with COFF proper (and also one
can have dedicated file-magics, which is a feature lacking in COFF).

May or may not resume work on this, had gotten distracted by writing a
hardware rasterizer module (with a whole lot of debugging effort to
follow), and fiddling with trying to get GLQuake into double-digit
territory.

But, at least, high single digits (with the ability to reach into the
double-digits) are better than low single digits (which, if-lucky, could
get into the high single digits...).

>>
>> I think you need to sing along with me...
>>
>> The world will be better for this,
>> That one man, scorned and covered with scars,
>> Still strove, with his last ounce of courage
> to be crucified.....

And in so doing brought atonement for the world...

>>
>> John Savard

BGB <cr88192@gmail.com> writes:
>On 9/13/2023 10:43 AM, MitchAlsup wrote:
>> On Wednesday, September 13, 2023 at 9:02:45 AM UTC-5, Quadibloc wrote:
>>> On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
>>>> On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
>>>
>>>>> Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
>>>
>>>> Well that only took 2 years longer than it should have.
>> <
>>> A number of the solutions I proposed to using variables of odd lengths
>>> would work with reasonable efficiency, such as using a 12-bit unit and
>>> simply using standard techniques for supporting access of unaligned
>>> operands in memory - basically, use dual-channel memory, and everything
>>> works just fine, with only a small overhead.
>>>
>>> But I wasn't satisfied since my goal is a blazingly-fast vector architecture,
>> <
>> I should note: almost all computers known in their day as being blazingly fast
>> were extremely simple......
>> <
>
>Yeah.
>
>Early on, maximizing clock speed seemed to be the ideal.
>More MHz, more instructions per second, more fast.

Early on, clock speeds were in the khz (e.g. PDP-8/E ran at 385 khz,
the "high speed" PDP-8/A at 666khz).

A controlling factor was the access time to magnetic core memory.

On Wednesday, September 13, 2023 at 11:01:18 AM UTC-6, BGB wrote:

> But, when there is an upper limit to MHz, it may become more practical
> not to try to build a race car, and instead build a dump-truck.

We are already at the dump-truck stage; that's what the x86-64 chips
in our computers are.

The stage beyond that is many race cars in parallel - chips with 128
RISC-V or ARM processors in parallel, that do even more than a
dump truck.

> And in so doing brought atonement for the world...

That may be, but Mitch got my reference wrong.

Causing needless expense to millers won't bring anyone
salvation. (The Impossible Dream > Man of la Mancha >
Don Quixote)

John Savard

On Wednesday, September 13, 2023 at 11:37:30 AM UTC-6, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:

> Early on, clock speeds were in the khz (e.g. PDP-8/E ran at 385 khz,
> the "high speed" PDP-8/A at 666khz).

> A controlling factor was the access time to magnetic core memory.

Your "early" is not his "early". His early is much more recent - before
Dennard Scaling died, back when we were at 65nm or so.

John Savard

On Wednesday, September 13, 2023 at 12:01:18 PM UTC-5, BGB wrote:
> On 9/13/2023 10:43 AM, MitchAlsup wrote:
> > On Wednesday, September 13, 2023 at 9:02:45 AM UTC-5, Quadibloc wrote:
> >> On Tuesday, September 12, 2023 at 1:09:38 PM UTC-6, MitchAlsup wrote:
> >>> On Tuesday, September 12, 2023 at 12:32:41 AM UTC-5, Quadibloc wrote:
> >>
> >>>> Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.
> >>
> >>> Well that only took 2 years longer than it should have.
> > <
> >> A number of the solutions I proposed to using variables of odd lengths
> >> would work with reasonable efficiency, such as using a 12-bit unit and
> >> simply using standard techniques for supporting access of unaligned
> >> operands in memory - basically, use dual-channel memory, and everything
> >> works just fine, with only a small overhead.
> >>
> >> But I wasn't satisfied since my goal is a blazingly-fast vector architecture,
> > <
> > I should note: almost all computers known in their day as being blazingly fast
> > were extremely simple......
> > <
> Yeah.
>
> Early on, maximizing clock speed seemed to be the ideal.
> More MHz, more instructions per second, more fast.
> The "More MHz" part being achieved by minimizing unnecessary logic.
>
>
> But, when there is an upper limit to MHz, it may become more practical
> not to try to build a race car, and instead build a dump-truck.
>
> Like, the race-car might be able to drive around faster, but the
> dump-truck can haul far more than the race-car could ever hope to manage.
> >> like the Cray I or the NEC SX-Aurora TSUBASA, its current spiritual successor,
> >> and so I wanted the ultimate in speed, with almost no overhead resulting from
> >> unusual memory widths.
> > <
> > These machines were designed to exploit cacheless multi-banked memory systems
> > with 4-64× the BW of a "mainframe" of that same time period.
> Now we have RAM modules with power-of-2 sizes for everything.
> Bus width: Power of 2 (typically 16-bits on the HW I have access to);
> Burst size: Power of 2 (typically 8x 16-bits);
> Row size: Power of 2;
> Row count: Also power of 2.
>
> No good way to throw any non-power-of-2 sizes in there without shooting
> oneself in the foot in the process.
<
The point was that to access as many banks concurrently as older supercomputers
one would need 4×{7+48+64} = 405 signal, pins all running at CPU frequency, per
CPU and some kind of non-blocking network between the memory ports and the
not-less than 64 DIMMs or 64 HBMs memories themselves, not the power of 2-ness
of the storage container. The interconnect between the CPU chip and the DRAM
chips would swamp the cost of the CPUs.
>
> And, even if one did, no standard software could be "easily" ported to
> it (since all of the software tends to assume a set of well-known
> power-of-2 sizes for each type, among other things...).
>
>
> Like, porting is already enough of a pain when one typically needs to
> rewrite parts of the code to deal with a non-standard OS and build
> setup, vs just being able to be like "./configure --target=whatever ...".
>
> But, still haven't gone up the curve of getting BGBCC to be a sufficient
> substitute for GCC/binutils to be able to get 'configure' and friends to
> play along with it (when I had started working on TKuCC, a sub-goal was
> to try to make it more closely mimic GCC/binutils commands and
> command-line arguments, *).
>
> *: By contrast, BGBCC was originally written to accept command-lines
> more like those given to MSVC, which are significantly different.
> So, for example, it needs to provide *-as/ *-ar / *-cc / etc, with
> similar behavior to that provided by GCC. Formats are slightly more
> flexible, but still need to have .o / .a / ... file extensions.
>
> So, for example, had ended up going for a non-standard "WOFF"
> object-format, rather than COFF or ELF, where in this case a "WOFF" if
> basically a modified version of the "WAD2" file format posing as an
> object module... This, in part, because "just throw the sections into a
> WAD" seemed like less effort than dealing with COFF proper (and also one
> can have dedicated file-magics, which is a feature lacking in COFF).
>
>
> May or may not resume work on this, had gotten distracted by writing a
> hardware rasterizer module (with a whole lot of debugging effort to
> follow), and fiddling with trying to get GLQuake into double-digit
> territory.
>
> But, at least, high single digits (with the ability to reach into the
> double-digits) are better than low single digits (which, if-lucky, could
> get into the high single digits...).
> >>
> >> I think you need to sing along with me...
> >>
> >> The world will be better for this,
> >> That one man, scorned and covered with scars,
> >> Still strove, with his last ounce of courage
> > to be crucified.....
> And in so doing brought atonement for the world...
<
In what metric ?
>
>
> >>
> >> John Savard

On Wednesday, September 13, 2023 at 2:00:29 PM UTC-5, Quadibloc wrote:
> On Wednesday, September 13, 2023 at 11:37:30 AM UTC-6, Scott Lurndal wrote:
> > BGB <cr8...@gmail.com> writes:
>
> > Early on, clock speeds were in the khz (e.g. PDP-8/E ran at 385 khz,
> > the "high speed" PDP-8/A at 666khz).
>
> > A controlling factor was the access time to magnetic core memory.
<
All early computers were balanced between CPU performance and
memory performance--often being in absolute lockstep. You don't make
the CPU so fast the memory system cannot feed the beast, and you don't
make the memory system so high performance the PCU cannot consume it.
<
> Your "early" is not his "early". His early is much more recent - before
> Dennard Scaling died, back when we were at 65nm or so.
>
> John Savard

On 9/13/2023 1:58 PM, Quadibloc wrote:
> On Wednesday, September 13, 2023 at 11:01:18 AM UTC-6, BGB wrote:
>
>> But, when there is an upper limit to MHz, it may become more practical
>> not to try to build a race car, and instead build a dump-truck.
>
> We are already at the dump-truck stage; that's what the x86-64 chips
> in our computers are.
>

Yeah.

I was thinking partly about some of the 1990s era RISC's, which were
apparently focused on trying to get the fastest clock-speeds around
(while otherwise focusing on overly minimalistic designs).

These were, however, not the architectures that survived into the 2000s.

> The stage beyond that is many race cars in parallel - chips with 128
> RISC-V or ARM processors in parallel, that do even more than a
> dump truck.
>

Probably true enough.

I suspect the current flock of processor designs are likely to run into
problems when Moore's Law comes to an end. There will be no real option
other than cutting cost in some areas. I would not expect x86 to hold up
much longer in this context.

There are likely to be limits though, like I don't expect that we will
see a return, for example, to things like aligned-only memory access (or
give up on things like byte-oriented memory access), ...

>> And in so doing brought atonement for the world...
>
> That may be, but Mitch got my reference wrong.
>
> Causing needless expense to millers won't bring anyone
> salvation. (The Impossible Dream > Man of la Mancha >
> Don Quixote)
>

I am not familiar with these references...

On 9/13/2023 2:00 PM, Quadibloc wrote:
> On Wednesday, September 13, 2023 at 11:37:30 AM UTC-6, Scott Lurndal wrote:
>> BGB <cr8...@gmail.com> writes:
>
>> Early on, clock speeds were in the khz (e.g. PDP-8/E ran at 385 khz,
>> the "high speed" PDP-8/A at 666khz).
>
>> A controlling factor was the access time to magnetic core memory.
>
> Your "early" is not his "early". His early is much more recent - before
> Dennard Scaling died, back when we were at 65nm or so.
>

Yeah, seems probably so.

I was imagining an era of CPUs that ran roughly 3 orders of magnitude
faster, where it seemed like processors like the DEC Alpha were claiming
clock-speeds that seemingly put everyone else to shame.

In the naivety of youth, it seemed like all this could go on forever.

Like, the general mindset of the era seemingly summed up in Weird Al's
"It's all about the Pentiums" song.

....

But, at least in terms of MHz, computers now are not *that* much faster
than what I had back when I was in high-school. Way more RAM and HDD
space, but MHz had mostly hit an impassable wall.

Now, HDDs and RAM have also began to slow down, and may also soon hit a
wall, ...

Though, by other metrics (other than MHz), performance comparison gets a
bit more weird.

Like, I can't really establish a good comparison between my project and
vintage computers, as things seem to quickly become a bit non-linear
(and trying to extrapolate things here keeps running into stuff that
"just doesn't make sense").

Well, also, I can't run benchmarks on stuff I don't have...

I can't even entirely classify whether performance is "good" or "bad"
relative to clock-speed, it seems to depend a lot on what I am looking
at (and the specifics of the piece of code that is being used as the
benchmark).

On 9/13/2023 5:53 PM, BGB wrote:
> On 9/13/2023 1:58 PM, Quadibloc wrote:

snip

>> Causing needless expense to millers won't bring anyone
>> salvation. (The Impossible Dream > Man of la Mancha >
>> Don Quixote)
>>
>
> I am not familiar with these references...

"The Impossible Dream" was a hit song (now a standard) from the 1965
Broadway musical, and later movie "Man of La Mancha", which was sort of
about the story of Don Quixote.

https://en.wikipedia.org/wiki/Man_of_La_Mancha

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup wrote:
> On Wednesday, September 13, 2023 at 2:00:29 PM UTC-5, Quadibloc wrote:
>> On Wednesday, September 13, 2023 at 11:37:30 AM UTC-6, Scott Lurndal wrote:
>>> BGB <cr8...@gmail.com> writes:
>>
>>> Early on, clock speeds were in the khz (e.g. PDP-8/E ran at 385 khz,
>>> the "high speed" PDP-8/A at 666khz).
>>
>>> A controlling factor was the access time to magnetic core memory.
> <
> All early computers were balanced between CPU performance and
> memory performance--often being in absolute lockstep. You don't make
> the CPU so fast the memory system cannot feed the beast, and you don't
> make the memory system so high performance the PCU cannot consume it.

Sometimes you make the CPU slightly slower just so you can take
advantage of the CPU clock for other needs: The original IMB PC chose
4.77273 MHz instead of the Intel-rated 5 MHz, just so that the CPU ran
at a fixed (4:3) ratio to the (US) TV signal!

The RAM chips ran at the CPU frequency, with a single read or write
operation taking 4 of these clock cycles, so in reality (after
subtracting the cycles lost to RAM refresh) we had a CPU that was very
close to 1 MB/second: Just count the number of bytes (code & data)
touched and that gave you the number of microseconds needed.

Quoting a post at ycombinator:

"At some point an IBM hardware design engineer made a leap: The Color
Graphics Adapter would need a 3.579545 MHz signal to create a color
subcarrier; one way to get that signal was to divide 14.31818 MHz by
four; 14.31818 MHz is only about 5% less than the maximum speed of the
Intel 8284 clock generator (which would divide it by three to get
4.77273 MHz for the 8088 processor). Thus by sacrificing 5% in
performance, around $0.50 could be saved in parts"

BTW, I seem to remember that the 8088 actually needed a 33% duty clock
signal, i.e. the base 15 MHz clock was divided into 3 parts with one
part on and two parts off!

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"