Scott Lurndal <scott@slp53.sl.home> schrieb:
> 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.

Reading about this (I am too old to have used core memory computers
myself), I found it interesting that there was a time when CPUs
were bound by core memory speeds. Caches helped then, but were
very expensive.

Then, with the introduction of semiconductor memory (at least some)
CPUs could be run much faster, for example the SuperNOVA SC.
Then, CPU speed started to overtake memory latency again, and
caches are now here to stay.

On Wednesday, September 13, 2023 at 8:02:45 AM UTC-6, Quadibloc wrote:

> 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

From what has followed in this thread, it's apparent
that some do not know the tune in order to sing along.

So here we go:
https://www.youtube.com/watch?v=dyd0ucV2MCM
https://www.youtube.com/watch?v=oo7VlD66ISM

As some may have felt that the song was supportive of U.S. military
action in Vietnam, Jack Jones sang it with slightly modified words:

https://www.youtube.com/watch?v=THY15gW2jBI

which were also used by Frank Sinatra when he sang the song.

https://www.youtube.com/watch?v=xoN7_lR1MOw

The line in this changed version
"To be better far than you are"
always reminds me of another song, though...

https://www.youtube.com/watch?v=BEnBcm3QIfs

which I find distracting.

John Savard

On Thursday, September 14, 2023 at 6:07:32 AM UTC-6, Quadibloc wrote:

> The line in this changed version
> "To be better far than you are"
> always reminds me of another song, though...
>
> https://www.youtube.com/watch?v=BEnBcm3QIfs
>
> which I find distracting.

Here's a modern version...
https://www.youtube.com/watch?v=6eL5rkmemis

and a famous animated version:
https://www.youtube.com/watch?v=Sy0mLLKJ0DU

John Savard

On Wednesday, September 13, 2023 at 10:02:45 AM UTC-4, 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.

I always thought 48 bit was a good length for FP, it just exceeds the precision
of hand-held calculators (about 11 digits). I have this weird hang-up about
multi-million dollar mainframes (circa-1975) having less accuracy than calculators.
(Obviously not true of the CDC systems).

Plus, you can store either 8 or 6 bit characters! :)

- Tim

Timothy McCaffrey <timcaffrey@aol.com> writes:
>On Wednesday, September 13, 2023 at 10:02:45=E2=80=AFAM UTC-4, Quadibloc wr=
>ote:
>> On Tuesday, September 12, 2023 at 1:09:38=E2=80=AFPM UTC-6, MitchAlsup wr=
>ote:=20
>> > On Tuesday, September 12, 2023 at 12:32:41=E2=80=AFAM UTC-5, Quadibloc =
>wrote:=20
>>=20
>> > > Instead, have 36 bit floats by having a 36-bit word and 9-bit bytes.=
>=20
>>=20
>> > Well that only took 2 years longer than it should have.
>> A number of the solutions I proposed to using variables of odd lengths=20
>> would work with reasonable efficiency, such as using a 12-bit unit and=20
>> simply using standard techniques for supporting access of unaligned=20
>> operands in memory - basically, use dual-channel memory, and everything=
>=20
>> works just fine, with only a small overhead.=20
>
>I always thought 48 bit was a good length for FP, it just exceeds the preci=
>sion
>of hand-held calculators (about 11 digits). I have this weird hang-up abo=
>ut
>multi-million dollar mainframes (circa-1975) having less accuracy than calc=
>ulators.
>(Obviously not true of the CDC systems).

And not true of the Burroughs systems, medium or large.

Although most of medium systems were doing fixed point, rather
than floating point, they still supported 100 digit operands.

>
>Plus, you can store either 8 or 6 bit characters! :)

Indeed, Burroughs moved from BCL (6-bit) to EBCDIC (8-bit)
on the Large systems in that timeframe.

On 9/14/2023 7:25 AM, Timothy McCaffrey wrote:
> On Wednesday, September 13, 2023 at 10:02:45 AM UTC-4, 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.
>
> I always thought 48 bit was a good length for FP, it just exceeds the precision
> of hand-held calculators (about 11 digits). I have this weird hang-up about
> multi-million dollar mainframes (circa-1975) having less accuracy than calculators.

Circa 1975 hand held calculators were just becoming popular, so weren't
an influence on the computer designs of that time.

However, the story goes that, in the 1950s or 60s, the Navy, a large
Univac customer, wanted computers with at least the precision of the
desktop electro-mechanical calculators of the day which was 10 decimal
digits. This forced the requirement of 36 bit integers.

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

On Thursday, September 14, 2023 at 8:25:50 AM UTC-6, Timothy McCaffrey wrote:

> I always thought 48 bit was a good length for FP, it just exceeds the precision
> of hand-held calculators (about 11 digits). I have this weird hang-up about
> multi-million dollar mainframes (circa-1975) having less accuracy than calculators.
> (Obviously not true of the CDC systems).
>
> Plus, you can store either 8 or 6 bit characters! :)

I tend to agree, although my view is a lilttle different.

Given the history of the IBM 7090 versus the IBM 360, apparently the 36-bit
floats of the former were suitable for many applications while the 32-bit
floats of the 360 weren't. That's why I chose it as the lowest available
precision, given information that it was useful.

But I included a 48-bit precision, designed to give 11 bits of precision and
an exponent range that included that of a pocket calculator - 10 ^ +/- 99.

It wasn't just to match the pocket calculator, though. I took pocket calculators
as one piece of evidence - along with a large number of old mathematical
tables that contained numbers to 10-bit precision. So it seemed to me that
before computers, 10 digit precision was considered a desirable maximum
for at least some types of scientific computation.

John Savard

On 9/14/2023 9:25 AM, Timothy McCaffrey wrote:
> On Wednesday, September 13, 2023 at 10:02:45 AM UTC-4, 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.
>
> I always thought 48 bit was a good length for FP, it just exceeds the precision
> of hand-held calculators (about 11 digits). I have this weird hang-up about
> multi-million dollar mainframes (circa-1975) having less accuracy than calculators.
> (Obviously not true of the CDC systems).
>
> Plus, you can store either 8 or 6 bit characters! :)
>

FWIW:
I had briefly considered using a "Binary64 truncated to 48 bits" format
for BJX2 (would have ignored the low 16 bits on input, and zeroed them
on output).

I ended up not going this direction though, as the cost savings didn't
really seem to be enough to justify the downsides.

If one wants the Fp<->Int conversion to handle 64-bit integers, FADD
still needs at least a 64-bit mantissa internally.

In both cases, I would have needed ~ 6 DSP48s for FMUL, just for full
Binary64 one needs to spend some extra LUTs to deal with stretching
things a little further:
For FMUL, one effectively needs to deal with two 54-bit numbers;
Mostly to add '01' as the top two bits of the unpacked mantissa.

The 18s*18s->36s / 17u*17u->34u DSP48 multipliers aren't quite
sufficient, but one can make up the difference by using some 3-bit
multipliers (which can be made out of LUTs).

Well, either this, or live with a Binary64 variant that effectively
ignores the low 3 bits of the mantissa...

In this case, the next size up is effectively a 68-bit mantissa built
using 10 DSPs, or 85-bit using 15 DSPs.

I had considered trying to use the latter in a "LongDouble" format
(effectively Binary128 with the mantissa truncated to 80 bits).

However, this was too expensive to be worthwhile.
The "cheaper" option being mostly to implement 128-bit ALU ops in order
to allow for faster software emulation (which, in turn, can give
full-precision Binary128).

Comparably, a Long-Double with a 64 or 68 bit mantissa didn't seem to
offer enough to really be worthwhile; but the cost overhead would have
been "less absurd".

One other wacky possibility being to implement full Binary128 in
hardware, just only FADD/FSUB and FCMP are fast; whereas FMUL/FDIV would
be handled with a Shift-Add multiplier unit (possibly, but would be
horridly slow).

Well, or alternatively, use internal pipelining trickery to build the
big multiplier via multiplexing a smaller multiplier (had evaluated and
rejected this idea for 64-bit multiplier, eventually ending up with a
shift-add unit instead, but this remains as possible, *).

*: This is faster but also somewhat more expensive than a Shift-Add
design. However, doing something in hardware is "kinda moot" if it will
be slower than doing it in software (and doing this in software being
one area where widening integer multiply and multiply-accumulate
instructions are useful...).

....

On 9/13/2023 7:26 PM, BGB wrote:
> 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").

Making good choices of what programs to benchmark is not trivial. If
you are talking about really older computers, the benchmark programs
Whetstone and Dhrystone used to be popular, and are, I believe, freely
available. Unfortualtely, at least for you, their successor, SPEC costs
money to get.

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

Yup. But clearly you should "broaden" your test suite from just old
games. There are lots of "standardized" benchmarks. Check out

https://en.wikipedia.org/wiki/Category:Benchmarks_(computing)

for a partial list.

I suspect others here can make better suggestions than I can.

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

On 9/14/2023 7:23 AM, Quadibloc wrote:
> On Thursday, September 14, 2023 at 6:07:32 AM UTC-6, Quadibloc wrote:
>
>> The line in this changed version
>> "To be better far than you are"
>> always reminds me of another song, though...
>>
>> https://www.youtube.com/watch?v=BEnBcm3QIfs
>>
>> which I find distracting.
>
> Here's a modern version...
> https://www.youtube.com/watch?v=6eL5rkmemis
>
> and a famous animated version:
> https://www.youtube.com/watch?v=Sy0mLLKJ0DU
>

I had not heard of any of this before...

Granted, these sorts of songs are not really my style.

I am more into things like House/EDM/Dubstep/etc.

Though, I guess apparently House was a descendant of the Disco genre,
some Disco is OK, but is a little dated.

Also, some amount of Tracker/Demoscene music is also cool, but this is
more oriented around a technology (Mod Players/Trackers) rather than a
genre in its own right (but, does generally tend to lean in a
Techno-like direction). Though, this also overlaps to some extent with
Chiptune music.

When I was much younger it was mostly stuff like Goth-Rock and
Industrial. Though, around my early/mid 20s, I started to get kinda
off-put by a lot of the more overt cultish and anti-religious aspects of
many of the bands in these genres.

So, then, it was mostly a lot of Trance and House...
At least (unlike most Goth Rock) they had something better to do than
bashing religion or singing what were effectively praise songs about
vampires or similar...

Meanwhile, my parents are more into Rock (or Classic Rock) and Metal.

Though, I suspect my transition in terms of preferred genres was also
associated with a general shift in views/attitudes.

Granted, never did quite make the switch over to more mainstream views
about the nature of value, seemingly instead just sort of making a move
from a more nihilistic outlook, to more identifying with existentialism
(and then face the annoyance that many people can't seem to see the
difference, and try to use the same condemnations/arguments against
existentialism as they would about nihilism).

Though, I suspect there are differences in some of my views compared
with the more traditional variants though. Some of the more traditional
philosophers needlessly assigning subjective intent to something (the
nature of meaninglessness) which is, by nature, entirely incapable of
subjective intent (the void has neither care nor malice; given it is, by
nature, nothingness).

And, apparently, some people seem to think that existentialism is
incompatible with theistic beliefs, but I disagree here, ... Like, I
come at it from a perspective more like it seeming like believing in
intrinsic values leads to a tangled mess of paradoxes, whereas in this
sense existentialism is a much simpler explanation (in terms of the
whole "Occam's Razor" thing); ...

Like, unless one assumes pantheism or similar, there is little reason to
assume any incompatibility here.

But, alas...

> John Savard

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 9/13/2023 7:26 PM, BGB wrote:
>> 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").
>
>Making good choices of what programs to benchmark is not trivial. If
>you are talking about really older computers, the benchmark programs
>Whetstone and Dhrystone used to be popular, and are, I believe, freely
>available. Unfortualtely, at least for you, their successor, SPEC costs
>money to get.
>
>
>> 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).
>
>Yup. But clearly you should "broaden" your test suite from just old
>games. There are lots of "standardized" benchmarks. Check out
>
>https://en.wikipedia.org/wiki/Category:Benchmarks_(computing)
>

This one is commonly used for core comparisions:

https://www.eembc.org/coremark/

BGB <cr88192@gmail.com> writes:
>On 9/14/2023 7:23 AM, Quadibloc wrote:
>> On Thursday, September 14, 2023 at 6:07:32 AM UTC-6, Quadibloc wrote:
>>
>>> The line in this changed version
>>> "To be better far than you are"
>>> always reminds me of another song, though...
>>>
>>> https://www.youtube.com/watch?v=BEnBcm3QIfs
>>>
>>> which I find distracting.
>>
>> Here's a modern version...
>> https://www.youtube.com/watch?v=6eL5rkmemis
>>
>> and a famous animated version:
>> https://www.youtube.com/watch?v=Sy0mLLKJ0DU
>>
>
>I had not heard of any of this before...
>
>
>Granted, these sorts of songs are not really my style.

You might find this a bit more interesting. It's all
instrumental, no vocals.

(GRP All Star Big Band)

https://www.youtube.com/watch?v=1RrrPxdo-H0

The were fun to see live.

Lately I've been binging Dream Theater.

On Thursday, September 14, 2023 at 1:46:45 PM UTC-5, Scott Lurndal wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >On 9/13/2023 7:26 PM, BGB wrote:
> >> 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").
> >
> >Making good choices of what programs to benchmark is not trivial. If
> >you are talking about really older computers, the benchmark programs
> >Whetstone and Dhrystone used to be popular, and are, I believe, freely
> >available. Unfortualtely, at least for you, their successor, SPEC costs
> >money to get.
> >
> >
> >> 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).
> >
> >Yup. But clearly you should "broaden" your test suite from just old
> >games. There are lots of "standardized" benchmarks. Check out
> >
> >https://en.wikipedia.org/wiki/Category:Benchmarks_(computing)
> >
> This one is commonly used for core comparisions:
>
> https://www.eembc.org/coremark/
<
Another (more towards the embedded side) is EMBench::

https://github.com/embench/embench-iot

On Thursday, September 14, 2023 at 12:40:28 PM UTC-5, BGB wrote:
> On 9/14/2023 9:25 AM, Timothy McCaffrey wrote:
> >
> FWIW:
> I had briefly considered using a "Binary64 truncated to 48 bits" format
> for BJX2 (would have ignored the low 16 bits on input, and zeroed them
> on output).
>
>
> I ended up not going this direction though, as the cost savings didn't
> really seem to be enough to justify the downsides.
>
> If one wants the Fp<->Int conversion to handle 64-bit integers, FADD
> still needs at least a 64-bit mantissa internally.
>
Overall, it is a quality of implementation metric--you either want quality
or you slice and dice to gain in other areas.
<
Me, I have IEEE transcendentals, and I have about 3/4 of them only require
57-bits (same as Goldschmidt or Newton-Raphson Division) the other 1/4
require 58-bits. But lower end machines (are there any these days??) really
want 64×64 integer multiply (and divide) so by expanding the multiplier
tree to 64×64, one gets a universal Function Unit that handles "everything
else" the ISA has to offer. In addition, instead of making a rounding error
1 out of 237 times, I now make a rounding error 1 out of 3E+6 times on the
transcendentals.
>

According to Thomas Koenig <tkoenig@netcologne.de>:
>Reading about this (I am too old to have used core memory computers
>myself), I found it interesting that there was a time when CPUs
>were bound by core memory speeds. Caches helped then, but were
>very expensive.

Caches arrived too late to help much.

Core memory was invented in the early 1950s (by multiple people
leading to lengthy and expensive patent fights) and was used
commercially in the IBM 704 in 1954. It was the dominant kind
of RAM until the early 1970s when MOS DRAM replaced it.

The first computer with a cache was the 360/85, announced in early
1968 but not shipped until the end of 1969. Before that the main way
that people sped up core memory was to divide it into a pair of
interleaved banks so the CPU could run alternating cycles in each bank
and overlap them. I think a few comptuters did four-way interleave. It
was also common to make the memory double width and fetch an even/odd
pair of words in each cycle.

In that era, you could build ROMs that were several times faster than
core, so microprogrammed machines running out of ROM could keep the
core RAM going at full speed so there was no performance penalty. I
think that's what they had in mind when they designed the Vax, but of
course their assumptions were almost immediately outdated.

--
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 Thursday, September 14, 2023 at 8:18:06 PM UTC-6, John Levine wrote:

> In that era, you could build ROMs that were several times faster than
> core, so microprogrammed machines running out of ROM could keep the
> core RAM going at full speed so there was no performance penalty.

And then there was the Packard-Bell 440, which was user-microprogrammable.

It used a form of RAM that ran five times faster than the machine's regular
core memory. That RAM was magnetic as well, and it was closely related to
core - it was BIAX, made by the Aeronutronics division of Ford.

John Savard

On Thursday, September 14, 2023 at 9:59:13 AM UTC-6, Quadibloc wrote:

> But I included a 48-bit precision, designed to give 11 bits of precision and
> an exponent range that included that of a pocket calculator - 10 ^ +/- 99..

Intermediate precision touches on what remains unsolved.

Changing from 36 bits and 60 bits to 36 bits and 72 bits gets to a conventional
architecture, where there is no need for complications in addressing or memory
structure to handle the single and double precision types.

A 54-bit intermediate precision can easily be addressed - and handling scalars
is simple enough on any system that can support unaligned operands. That
basically just requires dual channel memory and appropriate shifting circuitry
in the memory access path.

But that only works for scalars. What about vectors of intermediate precision
quantities?

One can have a vector register composed of a number of 72-bit registers,
and one can have it handle twice as many 36-bit values by having one in
each half of the register. That would make for rapid transfers to and from
memory that are simple conceptually.

If one does it that way, one could handle intermediate precision by doubling
the width of the individual portions of the vector register - so that it's made
up of 144-bit registers that can hold two double-precision numbers or four
single-precision numbers. That could also hold three intermediate precision
numbers... that are 48 bits in length.

Putting numbers like that in memory, though, makes for very complicated
addressing.

So perhaps the option that needs to be taken is to allow 48-bit numbers
to be saved either in vector form, or in scalar form, where scalar form is
a 54-bit cell with six bits of unused space!

John Savard

On 9/14/2023 2:12 PM, MitchAlsup wrote:
> On Thursday, September 14, 2023 at 12:40:28 PM UTC-5, BGB wrote:
>> On 9/14/2023 9:25 AM, Timothy McCaffrey wrote:
>>>
>> FWIW:
>> I had briefly considered using a "Binary64 truncated to 48 bits" format
>> for BJX2 (would have ignored the low 16 bits on input, and zeroed them
>> on output).
>>
>>
>> I ended up not going this direction though, as the cost savings didn't
>> really seem to be enough to justify the downsides.
>>
>> If one wants the Fp<->Int conversion to handle 64-bit integers, FADD
>> still needs at least a 64-bit mantissa internally.
>>
> Overall, it is a quality of implementation metric--you either want quality
> or you slice and dice to gain in other areas.

Full Binary64 and ability to do integer conversion with 64-bit values
seemed worthwhile.

Vs, say, partial precision and only being able to work with 32-bit
integer values...

Had also went with a Binary64 FPU rather than Binary32 partly as
Binary32 isn't really sufficient as a primary FPU; and needing to fall
back to software emulation for "double" almost defeats the point of
having an FPU.

Originally, there were no separate Binary32 ops, with Binary32 being
handled by always converting to Binary64 internally.

Now, technically some Binary32 ops exist indirectly via SIMD ops.

There are also FADDA/FSUBA/FMULA ops for operations which still use the
Binary64 format, but may use a faster but lower precision FPU (if this
low-precision FPU offers at least the equivalent of Binary32 precision).

Mostly this is because the low-precision FPU can offer 3-cycle latency
(pipelined) vs the usual 6 cycles (non-pipelined) needed for Binary64 ops.

> <
> Me, I have IEEE transcendentals, and I have about 3/4 of them only require
> 57-bits (same as Goldschmidt or Newton-Raphson Division) the other 1/4
> require 58-bits. But lower end machines (are there any these days??) really
> want 64×64 integer multiply (and divide) so by expanding the multiplier
> tree to 64×64, one gets a universal Function Unit that handles "everything
> else" the ISA has to offer. In addition, instead of making a rounding error
> 1 out of 237 times, I now make a rounding error 1 out of 3E+6 times on the
> transcendentals.

Far more minimal on my end.

For a while, there was no FDIV, only FADD/FSUB/FMUL.

The current FDIV instruction is still pretty slow though, and is still
regarded as an optional extension.

At present, it is still generally faster to do FDIV in software via an
implicit runtime call.

Note that dividing by a constant is implicitly converted into a multiply
by the reciprocal of the constant.

So, say:
y=x/2.0;
Becomes:
y=x*0.5;

John Levine <johnl@taugh.com> writes:
>According to Thomas Koenig <tkoenig@netcologne.de>:
>>Reading about this (I am too old to have used core memory computers
>>myself), I found it interesting that there was a time when CPUs
>>were bound by core memory speeds. Caches helped then, but were
>>very expensive.
>
>Caches arrived too late to help much.
>
>Core memory was invented in the early 1950s (by multiple people
>leading to lengthy and expensive patent fights) and was used
>commercially in the IBM 704 in 1954. It was the dominant kind
>of RAM until the early 1970s when MOS DRAM replaced it.
>
>The first computer with a cache was the 360/85, announced in early
>1968 but not shipped until the end of 1969.

I'm pretty sure that the B5500 had some form of small cache at
that point.

On Friday, September 15, 2023 at 1:21:50 AM UTC-5, BGB wrote:
> On 9/14/2023 2:12 PM, MitchAlsup wrote:
> > On Thursday, September 14, 2023 at 12:40:28 PM UTC-5, BGB wrote:
> >> On 9/14/2023 9:25 AM, Timothy McCaffrey wrote:
> >>>
> >> FWIW:
> >> I had briefly considered using a "Binary64 truncated to 48 bits" format
> >> for BJX2 (would have ignored the low 16 bits on input, and zeroed them
> >> on output).
> >>
> >>
> >> I ended up not going this direction though, as the cost savings didn't
> >> really seem to be enough to justify the downsides.
> >>
> >> If one wants the Fp<->Int conversion to handle 64-bit integers, FADD
> >> still needs at least a 64-bit mantissa internally.
> >>
> > Overall, it is a quality of implementation metric--you either want quality
> > or you slice and dice to gain in other areas.
> Full Binary64 and ability to do integer conversion with 64-bit values
> seemed worthwhile.
>
> Vs, say, partial precision and only being able to work with 32-bit
> integer values...
>
> Had also went with a Binary64 FPU rather than Binary32 partly as
> Binary32 isn't really sufficient as a primary FPU; and needing to fall
> back to software emulation for "double" almost defeats the point of
> having an FPU.
>
>
> Originally, there were no separate Binary32 ops, with Binary32 being
> handled by always converting to Binary64 internally.
>
> Now, technically some Binary32 ops exist indirectly via SIMD ops.
>
>
> There are also FADDA/FSUBA/FMULA ops for operations which still use the
> Binary64 format, but may use a faster but lower precision FPU (if this
> low-precision FPU offers at least the equivalent of Binary32 precision).
>
> Mostly this is because the low-precision FPU can offer 3-cycle latency
> (pipelined) vs the usual 6 cycles (non-pipelined) needed for Binary64 ops..
> > <
> > Me, I have IEEE transcendentals, and I have about 3/4 of them only require
> > 57-bits (same as Goldschmidt or Newton-Raphson Division) the other 1/4
> > require 58-bits. But lower end machines (are there any these days??) really
> > want 64×64 integer multiply (and divide) so by expanding the multiplier
> > tree to 64×64, one gets a universal Function Unit that handles "everything
> > else" the ISA has to offer. In addition, instead of making a rounding error
> > 1 out of 237 times, I now make a rounding error 1 out of 3E+6 times on the
> > transcendentals.
> Far more minimal on my end.
>
> For a while, there was no FDIV, only FADD/FSUB/FMUL.
>
> The current FDIV instruction is still pretty slow though, and is still
> regarded as an optional extension.
>
> At present, it is still generally faster to do FDIV in software via an
> implicit runtime call.
>
> Note that dividing by a constant is implicitly converted into a multiply
> by the reciprocal of the constant.
>
> So, say:
> y=x/2.0;
> Becomes:
> y=x*0.5;
<
This is legal in IEEE 754 when 1/x = y is exact.

On Friday, September 15, 2023 at 10:24:40 AM UTC-5, Scott Lurndal wrote:
> John Levine <jo...@taugh.com> writes:
> >According to Thomas Koenig <tko...@netcologne.de>:
> >>Reading about this (I am too old to have used core memory computers
> >>myself), I found it interesting that there was a time when CPUs
> >>were bound by core memory speeds. Caches helped then, but were
> >>very expensive.
> >
> >Caches arrived too late to help much.
> >
> >Core memory was invented in the early 1950s (by multiple people
> >leading to lengthy and expensive patent fights) and was used
> >commercially in the IBM 704 in 1954. It was the dominant kind
> >of RAM until the early 1970s when MOS DRAM replaced it.
> >
> >The first computer with a cache was the 360/85, announced in early
> >1968 but not shipped until the end of 1969.
<
CDC 6600 had a small loop buffer (like four 60-bit loop registers)
CDC 7600 greatly expanded this buffer.
<
> I'm pretty sure that the B5500 had some form of small cache at
> that point.

MitchAlsup wrote:
> On Friday, September 15, 2023 at 10:24:40 AM UTC-5, Scott Lurndal wrote:
>> John Levine <jo...@taugh.com> writes:
>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>> Reading about this (I am too old to have used core memory computers
>>>> myself), I found it interesting that there was a time when CPUs
>>>> were bound by core memory speeds. Caches helped then, but were
>>>> very expensive.
>>> Caches arrived too late to help much.
>>>
>>> Core memory was invented in the early 1950s (by multiple people
>>> leading to lengthy and expensive patent fights) and was used
>>> commercially in the IBM 704 in 1954. It was the dominant kind
>>> of RAM until the early 1970s when MOS DRAM replaced it.
>>>
>>> The first computer with a cache was the 360/85, announced in early
>>> 1968 but not shipped until the end of 1969.
> <
> CDC 6600 had a small loop buffer (like four 60-bit loop registers)
> CDC 7600 greatly expanded this buffer.
> <
>> I'm pretty sure that the B5500 had some form of small cache at
>> that point.

The CDC 6600 was released 1964 and the book "Considerations in Computer
Design – Leading up to the Control Data 6600" is dated 1963.

I tracked the cache concept back as far as this
1962 paper from The National Cash Register Company.

Considerations in the design of a computer with high
logic-to-memory speed ratio 1962
https://archive.computerhistory.org/resources/access/text/2020/10/102714096-05-01-acc.pdf

"Look-aside consists of a set of logic speed registers, which are invisible
to the programmer as they are never addressed and are not addressable by
the programmer. Thus, they are, philosophically, part of the main memory.
The conventional memory in this system will henceforth be called the
"store" and the entire memory, including look-aside, will be referred
to as "main memory".

Each look-aside register consists basically of three sections:
The first of these holds the contents of a store cell,
the second section holds the store address of that cell,
and the third is a usage indicator. (See Figure 1)
The store address portions of the look-aside registers are connected
to a comparator which has the ability to simultaneously compare the cell
addresses in look-aside with the address of a cell requested by the
system. If the address is in look-aside, an operation on the contents
of that cell may take place immediately without cycling the store.
If there is no matching address, the main store must be accessed.
When the store is accessed, the contents of the cell and the
cell address are placed in their respective places in look-aside."

EricP <ThatWouldBeTelling@thevillage.com> writes:
>MitchAlsup wrote:
>> On Friday, September 15, 2023 at 10:24:40 AM UTC-5, Scott Lurndal wrote:
>>> John Levine <jo...@taugh.com> writes:
>>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>>> Reading about this (I am too old to have used core memory computers
>>>>> myself), I found it interesting that there was a time when CPUs
>>>>> were bound by core memory speeds. Caches helped then, but were
>>>>> very expensive.
>>>> Caches arrived too late to help much.
>>>>
>>>> Core memory was invented in the early 1950s (by multiple people
>>>> leading to lengthy and expensive patent fights) and was used
>>>> commercially in the IBM 704 in 1954. It was the dominant kind
>>>> of RAM until the early 1970s when MOS DRAM replaced it.
>>>>
>>>> The first computer with a cache was the 360/85, announced in early
>>>> 1968 but not shipped until the end of 1969.
>> <
>> CDC 6600 had a small loop buffer (like four 60-bit loop registers)
>> CDC 7600 greatly expanded this buffer.
>> <
>>> I'm pretty sure that the B5500 had some form of small cache at
>>> that point.
>
>The CDC 6600 was released 1964 and the book "Considerations in Computer
>Design – Leading up to the Control Data 6600" is dated 1963.
>
>I tracked the cache concept back as far as this
>1962 paper from The National Cash Register Company.

The electrodata 220 had a "D" register which cached
an 11-digit word from memory[*] (and served as an store
buffer for some arithmetic operations). Circa 1954.

[*] Drum memory, in this case.

Scott Lurndal wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> MitchAlsup wrote:
>>> On Friday, September 15, 2023 at 10:24:40 AM UTC-5, Scott Lurndal wrote:
>>>> John Levine <jo...@taugh.com> writes:
>>>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>>>> Reading about this (I am too old to have used core memory computers
>>>>>> myself), I found it interesting that there was a time when CPUs
>>>>>> were bound by core memory speeds. Caches helped then, but were
>>>>>> very expensive.
>>>>> Caches arrived too late to help much.
>>>>>
>>>>> Core memory was invented in the early 1950s (by multiple people
>>>>> leading to lengthy and expensive patent fights) and was used
>>>>> commercially in the IBM 704 in 1954. It was the dominant kind
>>>>> of RAM until the early 1970s when MOS DRAM replaced it.
>>>>>
>>>>> The first computer with a cache was the 360/85, announced in early
>>>>> 1968 but not shipped until the end of 1969.
>>> <
>>> CDC 6600 had a small loop buffer (like four 60-bit loop registers)
>>> CDC 7600 greatly expanded this buffer.
>>> <
>>>> I'm pretty sure that the B5500 had some form of small cache at
>>>> that point.
>> The CDC 6600 was released 1964 and the book "Considerations in Computer
>> Design – Leading up to the Control Data 6600" is dated 1963.
>>
>> I tracked the cache concept back as far as this
>> 1962 paper from The National Cash Register Company.
>
> The electrodata 220 had a "D" register which cached
> an 11-digit word from memory[*] (and served as an store
> buffer for some arithmetic operations). Circa 1954.
>
> [*] Drum memory, in this case.

But did it have cache-like behavior - invisible to the programmer and
skips the memory access if the current location matches the last location?
Otherwise it is a memory data register.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Scott Lurndal wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> MitchAlsup wrote:
>>>> On Friday, September 15, 2023 at 10:24:40 AM UTC-5, Scott Lurndal wrote:
>>>>> John Levine <jo...@taugh.com> writes:
>>>>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>>>>> Reading about this (I am too old to have used core memory computers
>>>>>>> myself), I found it interesting that there was a time when CPUs
>>>>>>> were bound by core memory speeds. Caches helped then, but were
>>>>>>> very expensive.
>>>>>> Caches arrived too late to help much.
>>>>>>
>>>>>> Core memory was invented in the early 1950s (by multiple people
>>>>>> leading to lengthy and expensive patent fights) and was used
>>>>>> commercially in the IBM 704 in 1954. It was the dominant kind
>>>>>> of RAM until the early 1970s when MOS DRAM replaced it.
>>>>>>
>>>>>> The first computer with a cache was the 360/85, announced in early
>>>>>> 1968 but not shipped until the end of 1969.
>>>> <
>>>> CDC 6600 had a small loop buffer (like four 60-bit loop registers)
>>>> CDC 7600 greatly expanded this buffer.
>>>> <
>>>>> I'm pretty sure that the B5500 had some form of small cache at
>>>>> that point.
>>> The CDC 6600 was released 1964 and the book "Considerations in Computer
>>> Design – Leading up to the Control Data 6600" is dated 1963.
>>>
>>> I tracked the cache concept back as far as this
>>> 1962 paper from The National Cash Register Company.
>>
>> The electrodata 220 had a "D" register which cached
>> an 11-digit word from memory[*] (and served as an store
>> buffer for some arithmetic operations). Circa 1954.
>>
>> [*] Drum memory, in this case.
>
>But did it have cache-like behavior - invisible to the programmer and
>skips the memory access if the current location matches the last location?
>Otherwise it is a memory data register.

In the singular case of a branch to self :-).