On Friday, September 15, 2023 at 12:45:01 PM UTC-4, 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 loop buffer (called, confusingly, "the stack") was something like
8 words IIRC, the 6400 had one too, but it was only one or two words.
The Cyber 170/750 had a 12 word loop buffer, so probably the 7600 was the same.
(There was a lot in common between those two systems). Yes, I coded one
or two loops by hand trying to get it to fit in that 12 word buffer....

The 6000 series used 32 banks of memory, the Cyber 170/750 was down to 8 (even
though it used semiconductor memory, probably SRAM). The 7600 I think had 16 banks,
but I'm not sure about that.

- Tim

On Friday, September 15, 2023 at 4:42:17 PM UTC-5, Timothy McCaffrey wrote:
> On Friday, September 15, 2023 at 12:45:01 PM UTC-4, 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 loop buffer (called, confusingly, "the stack") was something like
> 8 words IIRC, the 6400 had one too, but it was only one or two words.
<
The 6600 "stack" allowed for 30-bit instructions to span stack entries,
the 6400 stack did not. "Design of a computer" Thornton 1970.
<
> The Cyber 170/750 had a 12 word loop buffer, so probably the 7600 was the same.
> (There was a lot in common between those two systems). Yes, I coded one
> or two loops by hand trying to get it to fit in that 12 word buffer....
>
> The 6000 series used 32 banks of memory, the Cyber 170/750 was down to 8 (even
> though it used semiconductor memory, probably SRAM). The 7600 I think had 16 banks,
> but I'm not sure about that.
>
> - Tim

On Friday, September 15, 2023 at 9:24:40 AM UTC-6, Scott Lurndal wrote:
> John Levine <jo...@taugh.com> writes:

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

Many computers, prior to the IBM System/360 Model 85, had small,
fast, scratchpad memories that they could use to speed up computation.

What originated with the model 85 was cache memory as we know it
today: a fast memory in which recently-used memory locations were
copied invisibly to the programmer.

John Savard

On Friday, September 15, 2023 at 7:17:28 PM UTC-5, Quadibloc wrote:
> On Friday, September 15, 2023 at 9:24:40 AM UTC-6, Scott Lurndal wrote:
> > John Levine <jo...@taugh.com> writes:
> > >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.
> Many computers, prior to the IBM System/360 Model 85, had small,
> fast, scratchpad memories that they could use to speed up computation.
>
> What originated with the model 85 was cache memory as we know it
> today: a fast memory in which recently-used memory locations were
> copied invisibly to the programmer.
<
The cache of the /85 combined with the pipeline of the /91 made for a machine
which was 2× as fast as the /91. That is: the /85 was the first machine that did
for the LDs/STs what the earlier buffers did for FETCH.
>
> John Savard

On 16/09/2023 01:17, Quadibloc wrote:
> On Friday, September 15, 2023 at 9:24:40 AM UTC-6, Scott Lurndal wrote:
>> John Levine <jo...@taugh.com> writes:
>
>>> 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.
>
> Many computers, prior to the IBM System/360 Model 85, had small,
> fast, scratchpad memories that they could use to speed up computation.
>
> What originated with the model 85 was cache memory as we know it
> today: a fast memory in which recently-used memory locations were
> copied invisibly to the programmer.
>
> John Savard

The IBM Stretch had a cache, called the 'virtual memory'!

BTW I much prefer the 360/85's original term: 'buffer'
to the now customary 'cache', since the ordinary meaning
of the latter is a hidden quantity, whereas the purpose
in a computer is the opposite -- to make something more,
not less, accessible.
--
Bill F.

On Friday, September 15, 2023 at 11:51:36 AM UTC-6, EricP wrote:

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

Thank you! I did a search for references to that paper, and it appears this is
indeed where the cache memory concept originated.

I've updated one part of my web page where the Model 85 is mentioned in
order to reflect this and give credit where credit is due.

John Savard

According to EricP <ThatWouldBeTelling@thevillage.com>:
>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

Interesting paper, thanks for digging it up. I liked the way it did
LRU replacement using the charge on a capacitor to remember how old an
entry is.

But it looks like this was a paper design with a very small cache, 7
48=bit words in their example, that they never built. The /85's cache
was 16K bytes, expandable to 32K, and it definitely worked.

There were lots of buffers that acted sort of like caches. The 360/91
had am 8 word instruction fetch buffer, and could recognize when a
backward branch created a loop that fit entirely in the buffer, at
which point it entered "loop mode" and ran the loop with no further
instruction fetches. For some kinds of loops it was worth twiddling
your assmebler code to get the loop aligned right so it fit in
the buffer.

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

Timothy McCaffrey <timcaffrey@aol.com> schrieb:
> 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,

The designers of the original ACS-1 (a supercomputer project by IBM)
would have agreed with you:

https://people.computing.clemson.edu/~mark/acs.html

Ironically, it was Gene Amdahl who shot down the 48-bit architecture in
favor of compatibility with /360, and then management decided that the
resulting computer would have been too fast. Amdahl left IBM (again)
and the rest is history.

On Thursday, September 14, 2023 at 11:06:36 PM UTC-6, Quadibloc wrote:

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

Further thought leads me to the conclusion that the architecture would need:

- scalar instructions for dealing with 48-bit FP, which would be stored in 54-bit
locations;
- the ability to move 54-bit floats either into the vector registers truncated to 48
bits, or expanded to 72 bits, and back again to memory
- a 144-bit temporary real format, and an extended precision built from two of them

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Thursday, September 14, 2023 at 11:06:36 PM UTC-6, Quadibloc wrote:
>
>> 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!
>
> Further thought leads me to the conclusion that the architecture would need:
>
> - scalar instructions for dealing with 48-bit FP, which would be stored in 54-bit
> locations;
> - the ability to move 54-bit floats either into the vector registers truncated to 48
> bits, or expanded to 72 bits, and back again to memory
> - a 144-bit temporary real format, and an extended precision built from two of them

Far too complicated. Look at the ACS-1: 24 or 48 bit instructions
(where the 24-bit instructions have a 24-bit immediate), 48-bit
registers, 48 or 96 bits for floating point.

I think they did halfword (24 bit) or word loads. Presumably,
today one would use loads at byte offsets.

24 bits is enough to put in three-register instructions, and 24
bits is a fairly big size for offsets.

Probably more than 95% of existing software would break due to
hardwired assumptions about bit sizes of integers, though :-)

John Levine wrote:
> According to EricP <ThatWouldBeTelling@thevillage.com>:
>> 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
>
> Interesting paper, thanks for digging it up. I liked the way it did
> LRU replacement using the charge on a capacitor to remember how old an
> entry is.

It also has an "eventual address register" :-)

> But it looks like this was a paper design with a very small cache, 7
> 48=bit words in their example, that they never built.

That design was also fully associative, and would have been built
from discrete transistors so each entry would have been fairly bulky.

To be useful it needs much higher density,
which the 360/85 gets from its custom memory chips (see below).

> The /85's cache
> was 16K bytes, expandable to 32K, and it definitely worked.
>
> There were lots of buffers that acted sort of like caches. The 360/91
> had am 8 word instruction fetch buffer, and could recognize when a
> backward branch created a loop that fit entirely in the buffer, at
> which point it entered "loop mode" and ran the loop with no further
> instruction fetches. For some kinds of loops it was worth twiddling
> your assmebler code to get the loop aligned right so it fit in
> the buffer.
>

I found some details for the 360/85 cache design.
It used IBM designed 64-bit bipolar memory chips,
mounted two in a 1/2 inch sq module.
Speed was 7 ns read, 12 ns write.

The cache line is 64B, and appears to be direct mapped.
Cache read access takes 2 cycles, one for tag one for data, pipelined.

360/85 had 80 ns cycle. Main memory was 1 us cores, 4 way interlieved.

On Saturday, September 16, 2023 at 10:43:19 AM UTC-5, EricP wrote:
> John Levine wrote:
> > According to EricP <ThatWould...@thevillage.com>:
> >> 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
> >
> > Interesting paper, thanks for digging it up. I liked the way it did
> > LRU replacement using the charge on a capacitor to remember how old an
> > entry is.
> It also has an "eventual address register" :-)
> > But it looks like this was a paper design with a very small cache, 7
> > 48=bit words in their example, that they never built.
> That design was also fully associative, and would have been built
> from discrete transistors so each entry would have been fairly bulky.
>
> To be useful it needs much higher density,
> which the 360/85 gets from its custom memory chips (see below).
<
Counter point: Mc 88020 had a 256-byte ICache with ~70% hit ratio.
This was just big enough so that Data references and instruction
references seldom conflicted on the external bus. I would call this
"useful".
<
> > The /85's cache
> > was 16K bytes, expandable to 32K, and it definitely worked.
> >
> > There were lots of buffers that acted sort of like caches. The 360/91
> > had am 8 word instruction fetch buffer, and could recognize when a
> > backward branch created a loop that fit entirely in the buffer, at
> > which point it entered "loop mode" and ran the loop with no further
> > instruction fetches. For some kinds of loops it was worth twiddling
> > your assmebler code to get the loop aligned right so it fit in
> > the buffer.
> >
> I found some details for the 360/85 cache design.
> It used IBM designed 64-bit bipolar memory chips,
> mounted two in a 1/2 inch sq module.
> Speed was 7 ns read, 12 ns write.
>
> The cache line is 64B, and appears to be direct mapped.
> Cache read access takes 2 cycles, one for tag one for data, pipelined.
>
> 360/85 had 80 ns cycle. Main memory was 1 us cores, 4 way interlieved.

On Friday, September 15, 2023 at 12:06:36 AM UTC-5, Quadibloc wrote:
> 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.
<
COBOL had it solved for fixed point arithmetic, and to some extent PL/1.
<
IEEE 754 has it solved at a handwaving level between rounding:: Things are
computed as if with infinite accuracy and then rounded to fit the defined
container.
<
The COBOL-PL/1 has too much specificity on the intermediate results that
only numerical methods people are happy. IEEE has too little specificity
that only hardware designers are challenged.
<
Neither seems to be acceptable for programming languages to expose
intermediate results to programmers.
>
> 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?
<
Quires (Posit) work for reduction operations (at considerable expense)
>
> 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 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.
>
The 100ns CDC 6600 was around 2× faster than IBM 360/65 at 60ns.....
Concurrency beats pipelining at least for scientific computing.
>
> 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.
<
A GPU with thousands of shader cores at 1ns beats a chip full of x86-64s
at 0.2ns...........................for embarrassingly parallel workloads.
>
> 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.
<
You should be comparing a number of WEC cars against 1 dump truck with the
same total loaded weight. WEC cars are less than 2000 pounds whereas a dump
truck is 80,000 pounds loaded, so 40 race cars versus 1 dump truck--which is
pretty much like a GPU against a CPU.
<

On Saturday, September 16, 2023 at 7:57:59 AM UTC-6, Thomas Koenig wrote:

> Far too complicated. Look at the ACS-1: 24 or 48 bit instructions
> (where the 24-bit instructions have a 24-bit immediate), 48-bit
> registers, 48 or 96 bits for floating point.

_That_ isn't an option.

The _simple_ part is: 36 bit single precision, 72 bit double precision. Just
like today's machines with 32 bit single precision and 64 bit double precision,
just longer.

Intermediate precision is allowed to be complicated by having both 48 bit
and 54 bit lengths to avoid accomodating it by introducing the complicated
memory organization I tried to avoid. It is a lower priority.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Saturday, September 16, 2023 at 7:57:59 AM UTC-6, Thomas Koenig wrote:
>
>> Far too complicated. Look at the ACS-1: 24 or 48 bit instructions
>> (where the 24-bit instructions have a 24-bit immediate), 48-bit
>> registers, 48 or 96 bits for floating point.
>
> _That_ isn't an option.

Why not?

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

GE 635, Honeywell 6000s

The One True byte width

On Saturday, September 16, 2023 at 3:15:17 PM UTC-6, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > On Saturday, September 16, 2023 at 7:57:59 AM UTC-6, Thomas Koenig wrote:
> >
> >> Far too complicated. Look at the ACS-1: 24 or 48 bit instructions
> >> (where the 24-bit instructions have a 24-bit immediate), 48-bit
> >> registers, 48 or 96 bits for floating point.
> >
> > _That_ isn't an option.
> Why not?

I thought that was explained in what followed. My primary goal
was to extend and improve on the current convention - single precision
32 bits, double precision 64 bits - by going to 36 bits for single
precision, as that was found adequate for many applications back
in the days of the 7090.

Adding intermediate precision is useful - because that precision
seems to correspond to what was considered the reasonablel
standard for precise scientific computations for quite some time -
but it's still secondary to the types which fill the standard single and
double precision.

And the other goal of the design is to avoid having to do things like
divide by three to address any variable in physical memory. So the
word size has to be designed around 36 bits, not anything else.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Saturday, September 16, 2023 at 3:15:17 PM UTC-6, Thomas Koenig wrote:
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>> > On Saturday, September 16, 2023 at 7:57:59 AM UTC-6, Thomas Koenig wrote:
>> >
>> >> Far too complicated. Look at the ACS-1: 24 or 48 bit instructions
>> >> (where the 24-bit instructions have a 24-bit immediate), 48-bit
>> >> registers, 48 or 96 bits for floating point.
>> >
>> > _That_ isn't an option.
>> Why not?
>
> I thought that was explained in what followed. My primary goal
> was to extend and improve on the current convention - single precision
> 32 bits, double precision 64 bits - by going to 36 bits for single
> precision, as that was found adequate for many applications back
> in the days of the 7090.

So, and improvement, but not too much of an improvement :-)

However, anything that is not a multiple of eight bits will not
fly - just try porting binutils to such an architecture.

In that case, it is probably better to go to an IEEE-like system
with 40 bits (eight bit exponent, one sign bit, leading bit always
1 - you can also do arithmetic using 32-bit instructions then).
If you want to look towards the past, the IBM 1130 had a format
like that.

For double precision, use the established 80-bit format used by
the 80x87.

mac <acolvin@efunct.com> schrieb:
>>> 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! :-)
>
> GE 635, Honeywell 6000s
>
> The One True byte width

According to Wikipedia, they had either six or nine bits.
Which one do you mean?
>

MitchAlsup wrote:
> On Friday, September 15, 2023 at 12:06:36 AM UTC-5, Quadibloc wrote:
>> 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.
> <
> COBOL had it solved for fixed point arithmetic, and to some extent PL/1.
> <
> IEEE 754 has it solved at a handwaving level between rounding:: Things are
> computed as if with infinite accuracy and then rounded to fit the defined
> container.
> <
> The COBOL-PL/1 has too much specificity on the intermediate results that
> only numerical methods people are happy. IEEE has too little specificity
> that only hardware designers are challenged.
> <
> Neither seems to be acceptable for programming languages to expose
> intermediate results to programmers.

I think the idea from the very beginning was that you would do
intermediate calculations in the next size up (i.e. float->double->quad)
and then do a final rounding to the target presision.

Only when the target precision is high enough that intermediate
cancellations/roundings doesn't matter and/or the algorithm is always
very well-behaved, like a NR iteration that doubles the precision for
every stage, should you expect to be able to do all calculation in the
same format.

The main problem here is of course that double is fast on pretty much
all architectures these days, while quad is either missing or much
(sometimes much, much) slower.

Secondarily, SIMD ops work very poorly or not at all with double-wide
intermediates.

Terje

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

On Saturday, September 16, 2023 at 2:10:52 PM UTC-6, MitchAlsup wrote:
> On Friday, September 15, 2023 at 12:06:36 AM UTC-5, Quadibloc wrote:

> > Intermediate precision touches on what remains unsolved.
> <
> COBOL had it solved for fixed point arithmetic, and to some extent PL/1.

By "intermediate precision" I mean 48-bit or 54-bit floating-point on the computer
which is built around a 36-bit word in order to provide 36-bit and 72-bit floats.

That's not a power-of-two length, so how do I keep using these numbers both
efficient and simple?

I wasn't referring to something for intermediate results, like the temporary
real of the 8087.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Saturday, September 16, 2023 at 2:10:52 PM UTC-6, MitchAlsup wrote:
>> On Friday, September 15, 2023 at 12:06:36 AM UTC-5, Quadibloc wrote:
>
>> > Intermediate precision touches on what remains unsolved.
>> <
>> COBOL had it solved for fixed point arithmetic, and to some extent PL/1.
>
> By "intermediate precision" I mean 48-bit or 54-bit floating-point on the computer
> which is built around a 36-bit word in order to provide 36-bit and 72-bit floats.
>
> That's not a power-of-two length, so how do I keep using these numbers both
> efficient and simple?

Make the architecture byte-addressable, with another width for the
bytes; possible choices are 6 and 9.

Six bits has the problem of not having being able to process ASCII,
so nine bits per byte is a logical choice. This also has the
advantage that the number of bytes per word is a power of two,
so no gaps in addressing, and a classic C loop over a string has
a chance of being implemented efficiently.

Then make your architecture capable of misaligned loads and stores
and an extra floating point format, maybe 45 bits, with 9 bits
exponent and 36 bits of significand.

If you start out with word-addressable machines, like all the old
IBM 704/UNIVAC 1100/GE 6xx/PDP-10 machines, you end up causing a
lot of hassle and/or wasting a lot of space.

On Sunday, September 17, 2023 at 10:46:12 AM UTC-5, Quadibloc wrote:
> On Saturday, September 16, 2023 at 2:10:52 PM UTC-6, MitchAlsup wrote:
> > On Friday, September 15, 2023 at 12:06:36 AM UTC-5, Quadibloc wrote:
>
> > > Intermediate precision touches on what remains unsolved.
> > <
> > COBOL had it solved for fixed point arithmetic, and to some extent PL/1..
<
> By "intermediate precision" I mean 48-bit or 54-bit floating-point on the computer
> which is built around a 36-bit word in order to provide 36-bit and 72-bit floats.
<
The COBOL programmer could specify the number of digits and the position
of the decimal point for the operands, intermediates and results (PICTURE)
in digit units.
>
> That's not a power-of-two length, so how do I keep using these numbers both
> efficient and simple?
>
> I wasn't referring to something for intermediate results, like the temporary
> real of the 8087.
>
> John Savard

In article <ue788u$4u5l$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

Quadibloc <jsavard@ecn.ab.ca> schrieb:

> By "intermediate precision" I mean 48-bit or 54-bit floating-point
> on the computer which is built around a 36-bit word in order to
> provide 36-bit and 72-bit floats.

I don't understand why you feel this is valuable. Are there any
architectures that have been used since about 1970 (when the Atlas
machines were shut down) that provide it? Is there software suffering
because it doesn't have it and needs to make do with double precision? No
architecture can do everything efficiently.

> If you start out with word-addressable machines, like all the old
> IBM 704/UNIVAC 1100/GE 6xx/PDP-10 machines, you end up causing a
> lot of hassle and/or wasting a lot of space.

Amen to that. I have never worked on one, but I've done enough BCPL to
get the idea.

John