On Monday, July 10, 2023 at 11:19:41 AM UTC-5, BGB wrote:
> On 7/9/2023 8:56 PM, MitchAlsup wrote:
>

> >> Well:
> >> MOV Imm25s, R0
> >> Is sort of a sledgehammer solution, but like, it is workable in the
> >> majority of cases...
> > <
> > MOV Rd,#123456789abcdef
> > <
> > works in all cases..........
<
> The ASM will work, but what it will generate will vary...
<
It generates::
<
OpCode = 001100, Rd, Rs1=0,{D=1,S1=1,S2=1},Rs3=0,Rs2=0
0x9abcdef
0x12345678
>
> Jumbo=True:
> 96-bit Jumbo-load;
> Executes in 1-cycle.
>
> Jumbo=False, Rn=R0..R31
> MOV 0x0123, Rd
> LDSH 0x4567, Rd
> LDSH 0x89AB, Rd
> LDSH 0xCDEF, Rd
>
> Can partly ignore R32..R63 for the false case, as anything with XGPR is
> probably also going to have Jumbo.
>
> Theoretical though:
> MOV 0x0123, R0
> LDSH 0x4567, R0
> LDSH 0x89AB, R0
> LDSH 0xCDEF, R0
> MOV R0, Rd
<
See how much easier it is with universal constants.
<
>
> > I use the equivalent of::
> > <
> > LDA IP,[any AGEN you want]
> > <
> Essentially N/E in my case.
>
> Could fake it as:
> LEA.x ..., R1
> JMP R1
<
Still eating instructions and registers and power.......
<
> > <
> > Why have a limit ?? My GOT can be 62-bits in size leaving code and data another
> > 62-bits without encroaching on OS space.
<
> I don't generally use a GOT, rather direct PC-rel for internal calls.
<
Internal calls use CALL, GOT calls use CALX, re-linked modules use CALA.
>
> The import/export tables may be managed by the PE/PEL loader.
>
> Where, say:
> __declspec(dllimport) int TkWhatever();
> Flags an import, but one needs to link against the DLL so the compiler
> knows what DLL has the definition, and/or use a specialized listing file
> (essentially a list of DLL exports).
>
> This being as opposed to using "import libraries" or similar (but, the
> listings would serve a similar role to import libraries). Mostly needed
> because the import table encodes the DLL (say, "SOMEDLL!TkWhatever").
>
> But, generally, the compiler can figure out roughly how big the program
> is going to be and what sort of branches it needs to use (for actual
> separate compilation, would need a "memory model" or similar).
>
>
> Can note that it is not currently possible to share global variables
> across DLL boundaries, only imported/exported functions.
>
Shame, shame; a linked module should resolve all extern names it
has memory for.
>
> Some of this might have been different had I used ELF as a basis instead.

> > But you do have the ability to fix it, do you not ??
> I would need some way for the assembler to know which notation is in use
> (and/or a bulk rewrite of all the ASM code).
>
> Otherwise, the assembler has no way to look at:
> ADD R4, R5, R6
> And know which register is the destination...
> R4=R5+R6
> Or:
> R6=R4+R5
>
A flag ?? An environment variable ??

On 7/10/2023 10:38 AM, Stephen Fuld wrote:
> On 7/10/2023 2:33 AM, Terje Mathisen wrote:
>> John Levine wrote:
>>> According to BGB  <cr88192@gmail.com>:
>>>>> The original 68000 came in 16 and 8 bit bus versions, just like the
>>>>> 8086 and 8088.
>>>>>
>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>>
>>>> I guess a question is if it had been used in the PC instead of x86, if
>>>> Motorola could have then made it performance competitive with what
>>>> later
>>>> x86 systems became?...
>>>
>>> Hard to say.  At that point Intel just executed better than Moto.
>>>
>>>> OTOH, the instruction encoding does seem at least cleaner than x86...
>>>
>>> No S* Sherlock.  And the huge win of flat rather than segmented
>>> addressing.
>>>
>>>> I guess another mystery could have been if a 32-bit RISC design could
>>>> have been made more viable with an 8 or 16 bit memory bus?...
>>>>
>>>>  From what I can gather, processors from that era didn't really use L1
>>>> or L2 caches though. This wouldn't likely bode well.
>>>
>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>> and i486 in 1989.
>>
>> That 486 had a combined code/data cache of just 8 KB, and that was
>> still enough to make a huge difference:
>
> Yup.  Since we all know that increasing cache size is a diminishing
> returns game, it logically follows that the first bit of cache provides
> the most return, i.e. performance gain.
>

Yeah.

Say, an 8K cache gives you a 75% hit rate, 16K gives 90%, and 32K gives
95%...

Still not so good with a 1K or 2K cache though.

A 16-byte or 32-byte "1-line" or "2-line" cache performs pretty awful,
but is one of the smallest designs I have.

Paying the cost of, say, a 16K L1 cache is "decidedly worth it" in terms
of performance.

Going much beyond 32K seems to be kinda moot.

I have had mixed results with associative caches, so have mostly stuck
with direct-mapped caches.

Partly it is because a design compromise I had made to reduce the cost
of an associative cache ends up hurting its effectiveness.

Cheap design (A/B cache):
Only A contains Dirty lines;
B is effectively exclusive to clean lines.
Where, on a miss:
A&B clean:
Copy A to B
Load new line into A.
A dirty, Load:
Load into B.
A dirty, Store:
Write A to RAM;
Swap A and B;
Load new line into A.

Works OK if the task is load-dominated, but hurts with code that does a
lot of stores.

Doom and similar perform worse with this style of cache design than with
a direct-mapped cache, and also direct mapped is cheaper (and passes
timing more easily).

A more effective cache is to have both A and B able to hold dirty lines:
Miss:
If B is Dirty, write to RAM;
Copy A to B;
Load new line into A.
Store may update either the A or B sets.

But, this cache design ended up more expensive in my tests, despite
being conceptually simpler.

Effectively, such a cache would work on 4 lines at a time:
A-Even, A-Odd, B-Even, B-Odd
With two sets of Store-line handling (for both A and B).

A possible intermediate compromise would be to allow A|B to hold Dirty
lines, but Store may only happen to A, causing the A-Miss/B-Hit store to
effectively swap the A and B lines during the operation.

>
>> I had written a near-perfect Game-of-Life competition entry: If the
>> target had been the 386 I might have won, but with the 486 David
>> Stafford came up with an algorithm which could fit most of the problem
>> space inside those 8 KB. I the end his entry ended up twice as fast as
>> my code.
>
> I certainly believe that.  I recall that some time ago we had a
> discussion here about sort algorithms, and someone pointed out a paper
> that showed (on DEC ALPHA, IIRC) a cache aware algorithm that
> significantly outperformed any non cache aware algorithms.
>
>

Cache is still a big issue in my case...

On the current biggest FPGA I have (an XC7A200T), there is a tradeoff
between 512K and 1MB of L2 cache:
512K, works pretty OK;
1MB eats all the BRAM and is prone to fail timing...
But, causes L2 miss rate in Doom to effectively fall off.

Say (for the ~ 10% of requests that have an L1 miss):
512K: 70% L2 hit rate.
1MB: 93% L2 hit rate.

This can make the difference between ~ 16-20 fps and ~ 26-30 fps
(somewhat increasing the effective MIPs rate of the CPU due to fewer L2
misses).

But, as I had found recently, there is still a lot of lost performance
in the L1 Miss / L2 Hit case.

....

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, July 9, 2023 at 9:51:48=E2=80=AFPM UTC-5, BGB wrote:
>> On 7/9/2023 3:41 PM, John Levine wrote:=20
>> > According to BGB <cr8...@gmail.com>:=20
>> >>> The original 68000 came in 16 and 8 bit bus versions, just like the 8=
>086 and 8088.=20
>> >>>=20
>> >>> Legend says that if Moto had been able to ship the 68008 in quantity,=
>=20
>> >>> IBM would have used it in the IBM PC rather than the 8088. If only.=
>=20
>> >>=20
>> >> I guess a question is if it had been used in the PC instead of x86, if=
>=20
>> >> Motorola could have then made it performance competitive with what lat=
>er=20
>> >> x86 systems became?...=20
>> >=20
>> > Hard to say. At that point Intel just executed better than Moto.=20
>> >
>> Could be.=20
>> Either that, or there was some architectural factor at play.
><
>Cost !!
>8088 was in a smaller package than 68008.
><
>> >> OTOH, the instruction encoding does seem at least cleaner than x86...=
>=20
>> >=20
>> > No S* Sherlock. And the huge win of flat rather than segmented addressi=
>ng.=20
>> >
>> That hardware x86 decoders work at all is kind of impressive in a way...
>> >> I guess another mystery could have been if a 32-bit RISC design could=
>=20
>> >> have been made more viable with an 8 or 16 bit memory bus?...=20
>> >>=20
>> >> From what I can gather, processors from that era didn't really use L1=
>=20
>> >> or L2 caches though. This wouldn't likely bode well.=20
>> >=20
>> > Cache? What's a cache? The PC was shipped in 1981 and the first=20
>> > general purpose CPU chips I know with a cache were the 68030 in 1987=20
><
>A whooping 256 bytes
><
>> > and i486 in 1989.
><
>A whooping 8K bytes.
><
>You forgot Mc88100--88200 was a 16KB 4-way set associative cache
>with 64-entry fully associative TLB in '88-or so.

Which required three chips - one 88100 and two 88200.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 7/10/2023 2:33 AM, Terje Mathisen wrote:
>> John Levine wrote:

>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>> and i486 in 1989.
>>
>> That 486 had a combined code/data cache of just 8 KB, and that was still
>> enough to make a huge difference:
>
>Yup. Since we all know that increasing cache size is a diminishing
>returns game,

Is it? LLC is getting bigger (and wider as core counts increase)
annually. The end game will be DRAM with single cycle latency making
cache irrelevent. Someday.

On 7/10/2023 11:20 AM, MitchAlsup wrote:
> On Sunday, July 9, 2023 at 9:51:48 PM UTC-5, BGB wrote:
>> On 7/9/2023 3:41 PM, John Levine wrote:
>>> According to BGB <cr8...@gmail.com>:
>>>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>>>
>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>>
>>>> I guess a question is if it had been used in the PC instead of x86, if
>>>> Motorola could have then made it performance competitive with what later
>>>> x86 systems became?...
>>>
>>> Hard to say. At that point Intel just executed better than Moto.
>>>
>> Could be.
>> Either that, or there was some architectural factor at play.
> <
> Cost !!
> 8088 was in a smaller package than 68008.
> <

OK.

8088 was apparently DIP40 with multiplexed Address/Data lines.

Looks like the main difference here between 8086 and 8088 was that 8086
had 16 pins being multiplexed Address/Data, and 8088 had 8 pins multiplexed.

Looks like 68008 was in 48 and 52 pin variants. OK.

>>>> OTOH, the instruction encoding does seem at least cleaner than x86...
>>>
>>> No S* Sherlock. And the huge win of flat rather than segmented addressing.
>>>
>> That hardware x86 decoders work at all is kind of impressive in a way...
>>>> I guess another mystery could have been if a 32-bit RISC design could
>>>> have been made more viable with an 8 or 16 bit memory bus?...
>>>>
>>>> From what I can gather, processors from that era didn't really use L1
>>>> or L2 caches though. This wouldn't likely bode well.
>>>
>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>> general purpose CPU chips I know with a cache were the 68030 in 1987
> <
> A whooping 256 bytes
> <

Better than nothing...

>>> and i486 in 1989.
> <
> A whooping 8K bytes.
> <

Likely 8K could have been fairly effective.

> You forgot Mc88100--88200 was a 16KB 4-way set associative cache
> with 64-entry fully associative TLB in '88-or so.
> <

In my case, I am mostly using 16K or 32K of direct-mapped L1.

L2 size depending on FPGA:
XC7S50: 64K
XC7A100: 128K or 256K
XC7A200: 512K or 1MB
Though, 1MB seems to be "pushing it".
Eats all the Block-RAM, pushes some stuff over to LUTRAM.

For the XC7S25, needed to use smaller LUTRAM L1 caches, with the L2
itself functioning like RAM (because the CMod-S7 lacks any external RAM).

Was generally using direct-mapped L2 cache (had experimented with
set-associative L2, with mixed results).

The TLB is comparably large, 256x 4-way (so, 1024 total TLBEs).
For XC7S50, can drop to 64x 4-way (256 TLBEs).

This is generally with a 16K page-size.
It is 4-way in 48-bit address mode, but drops to 2-way in 96-bit address
mode (with effectively 256-bit TLBEs).

With external DRAM access in this case being around 36 clock cycles per
cache-line.

This consists of a DDR module with a 16-bit interface being run at 50
MHz with DLL disabled. It isn't actually designed to run at this
clock-speed; but apparently this exists and is intended to be used for a
lower-power / "sleep mode"...

Though, ironically, it seems that if I were to make the RAM faster,
would need to come up with a faster bus design to make use of it.

Likely, this would imply something like a "star bus", with messages
being routed across hubs and likely with each node needing to be
identified with a hierarchical address that specifies where in the core
to route each message (as opposed to the address+sequence being used
solely on the return path for the sender to know which responses belong
to it).

Though, the likely option would be that this would be a "trivial
modification" of the existing ringbus, just with the shared ring being
replaced by "hubs" and likely a partial rework of how the TLB works
(would need a dedicated L1 TLB in each L1 cache, rather than an optional
"microTLB" and just in the L1 D$).

....

>> OK.
>>
>> As can be noted, my familiarity with computers from that era is a bit
>> sketchy at times...

On Monday, July 10, 2023 at 12:03:52 PM UTC-5, BGB wrote:
> On 7/10/2023 10:38 AM, Stephen Fuld wrote:
> > On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> >> John Levine wrote:
> >>> According to BGB <cr8...@gmail.com>:
> >>>>> The original 68000 came in 16 and 8 bit bus versions, just like the
> >>>>> 8086 and 8088.
> >>>>>
> >>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
> >>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
> >>>>
> >>>> I guess a question is if it had been used in the PC instead of x86, if
> >>>> Motorola could have then made it performance competitive with what
> >>>> later
> >>>> x86 systems became?...
> >>>
> >>> Hard to say. At that point Intel just executed better than Moto.
> >>>
> >>>> OTOH, the instruction encoding does seem at least cleaner than x86....
> >>>
> >>> No S* Sherlock. And the huge win of flat rather than segmented
> >>> addressing.
> >>>
> >>>> I guess another mystery could have been if a 32-bit RISC design could
> >>>> have been made more viable with an 8 or 16 bit memory bus?...
> >>>>
> >>>> From what I can gather, processors from that era didn't really use L1
> >>>> or L2 caches though. This wouldn't likely bode well.
> >>>
> >>> Cache? What's a cache? The PC was shipped in 1981 and the first
> >>> general purpose CPU chips I know with a cache were the 68030 in 1987
> >>> and i486 in 1989.
> >>
> >> That 486 had a combined code/data cache of just 8 KB, and that was
> >> still enough to make a huge difference:
> >
> > Yup. Since we all know that increasing cache size is a diminishing
> > returns game, it logically follows that the first bit of cache provides
> > the most return, i.e. performance gain.
> >
> Yeah.
>
> Say, an 8K cache gives you a 75% hit rate, 16K gives 90%, and 32K gives
> 95%...
>
> Still not so good with a 1K or 2K cache though.
<
The 256-byte cache on 68020 was just big enough so that code fetches
did not overly delay data accesses. {{And for that purpose is was big
enough}}

On Monday, July 10, 2023 at 12:25:48 PM UTC-5, Scott Lurndal wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> >> John Levine wrote:
>
> >>> Cache? What's a cache? The PC was shipped in 1981 and the first
> >>> general purpose CPU chips I know with a cache were the 68030 in 1987
> >>> and i486 in 1989.
> >>
> >> That 486 had a combined code/data cache of just 8 KB, and that was still
> >> enough to make a huge difference:
> >
> >Yup. Since we all know that increasing cache size is a diminishing
> >returns game,
<
> Is it? LLC is getting bigger (and wider as core counts increase)
> annually. The end game will be DRAM with single cycle latency making
> cache irrelevent. Someday.
<
DRAM has stayed stubbornly at 20ns since 2000. You can run more
data over the pins, but the banks inside have a fundamental timing
that is going no where.

On 7/9/23 3:41 PM, John Levine wrote:

> Cache? What's a cache? The PC was shipped in 1981 and the first
> general purpose CPU chips I know with a cache were the 68030 in 1987
> and i486 in 1989.

MC68020 had an instruction cache. 64 32 bit entries.

--
http://davesrocketworks.com
David Schultz

On 7/10/2023 10:25 AM, Scott Lurndal wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:
>>> John Levine wrote:
>
>>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>>> and i486 in 1989.
>>>
>>> That 486 had a combined code/data cache of just 8 KB, and that was still
>>> enough to make a huge difference:
>>
>> Yup. Since we all know that increasing cache size is a diminishing
>> returns game,
>
> Is it?

Yes. See below.

> LLC is getting bigger (and wider as core counts increase)
> annually.

While that is true, it doesn't contradict my point. Diminished returns
are still better than no returns, and designers haven't come up with a
better alternative use for the die space.

> The end game will be DRAM with single cycle latency making
> cache irrelevent. Someday.

Others with more hardware knowledge can chime in here, but I don't think
so. Just the DRAM organization requiring RAS then CAS means two cycles
even if there is no more internal latency, which is still a very tall order.

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

On Monday, July 10, 2023 at 8:25:48 PM UTC+3, Scott Lurndal wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> >> John Levine wrote:
>
> >>> Cache? What's a cache? The PC was shipped in 1981 and the first
> >>> general purpose CPU chips I know with a cache were the 68030 in 1987
> >>> and i486 in 1989.
> >>
> >> That 486 had a combined code/data cache of just 8 KB, and that was still
> >> enough to make a huge difference:
> >
> >Yup. Since we all know that increasing cache size is a diminishing
> >returns game,
> Is it? LLC is getting bigger (and wider as core counts increase)
> annually.

Look at LLC per core.
Intel Penryn (2007) had 3 MB of L2 per core.
AMD Zen4 (2022) has 4 MB of L3 per core.
So 30% increase in 15 years. And even that moderate increase is not free
in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
more like 6-7 ns.

> The end game will be DRAM with single cycle latency making
> cache irrelevent. Someday.

Do you predict that your future CPUs will have clock frequency = 25-30 MHz ?

John Levine <johnl@taugh.com> writes:
> Later on IBM made several PC add-in cards that ran 370 code. They
> worked fine but sold poorly because nobody wanted to run mainframe
> software on PCs.

VM370/CMS had increasingly gotten bloated (memory and disk I/O) since
CP67/CMS days running on 256kbyte 360/67. Prototype XT/370 had 384kbyte
370 memory and all I/O was done with messages with the 8088 that did
actual physical I/O. I did various (single CMS user) benchmarks showing
there was lot of paging requiring messaging 8088 to do page i/o on the
XT hard disk (something like 5times slower than mainframe disks). They
blamed me for having to upgrade to 512kbyte 370 memory before 1st
shipments to customers (to address frequent page thrashing).

Then CMS interactive applications had gotten quite filesystem intensive
(especially compared to similar PC applications that were highly
optimize to do lots of processing with minimal filesystem operations)
.... again lots of disk I/O via messages with the 8088 (doing actual I/O
with XT hard disk significantly slower than mainframe disks).

One of my hobbies after joining IBM was enhanced production operating
systems for internal datacenters ... I had several internal datacenters
getting 90precentile .11sec system trivial interactive response (compare
to sandard VM370 with similar mainframe hardware configurations and
workloads getting avg .2-.3sec system trivial interactive response).
XT/370 CMS trivial interactive response tended to be worse than both
similar, native PC applications as well many standard mainframe systems.

VM370/CMS had also tried to optimize caching of frequently/commonly used
applications/operations (in the larger real mainframe memories, somewhat
masking the bloat since CP67/CMS) ... which would always result in real
disk I/O on XT/370). XT/370 got about 100KIPS (.1MIPS) 370 ... but also
compared poorly with multi-user 370/125 (which was compareable memory
and processing as XT/370 ... but much faster real disk I/O).

caveat: VM370/CMS was never officially available for 370/125 ... but
I got con'ed into doing it for a customer ... eliminating some of the
bloat that occured in the CP67/CMS -> VM370/CMS transition.

trivia: mainframe balanced configuration for target throughput; mid-80s,
the largest IBM mainframe 3090 was initially configured with number of
I/O channels expected to give target throughput. The disk division had
come out with 3380 having 3mbyte/sec transfer (compared to previous 3330
having .8mbyte/sec). However the associated disk controller, 3880
supported 3mbyte/sec transfer, but had an extremely slow processor for
all other operations (compared to the 3330, 3830 disk controller) which
significantly increased elapsed channel busy per operation (offsetting
the faster transfer). Eventually 3090 realized that they had to
significantly increase the number of channels (to compensate for the
controller protocol channel busy overhead). Eventually marketing respun
it as the big increase in number of channels represented a fabulous I/O
machine (when it was necessary to compensate for the 3880 controller
busy).

Something similar happened with the IBM "FICON" protocol running over
Fibre Channel Standard. The most recent public, published numbers I've
found was 2010 z196 "peak I/O" benchmark getting 2M IOPS with 104 FICON
(running over 104 FCS). About the same time a FCS was announced for
E5-2600 blades claiming over a million IOPS (two such FCS having higher
throughput than 104 FICON running over 104 FCS).

--
virtualization experience starting Jan1968, online at home since Mar1970

According to BGB <cr88192@gmail.com>:
>>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.

>> Cost !!
>> 8088 was in a smaller package than 68008.

No, it was definitely availability.

>8088 was apparently DIP40 with multiplexed Address/Data lines.
>
>Looks like the main difference here between 8086 and 8088 was that 8086
>had 16 pins being multiplexed Address/Data, and 8088 had 8 pins multiplexed.

That's it. Otherwise they were the same.

The 8089 I/O processor also had nearly the same pinout. Intel expected
you to use a combination of them but the CPUs were good enough that
people skipped the 8089s.

--
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 Monday, July 10, 2023 at 9:25:32 PM UTC+3, MitchAlsup wrote:
> On Monday, July 10, 2023 at 12:25:48 PM UTC-5, Scott Lurndal wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > >On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> > >> John Levine wrote:
> >
> > >>> Cache? What's a cache? The PC was shipped in 1981 and the first
> > >>> general purpose CPU chips I know with a cache were the 68030 in 1987
> > >>> and i486 in 1989.
> > >>
> > >> That 486 had a combined code/data cache of just 8 KB, and that was still
> > >> enough to make a huge difference:
> > >
> > >Yup. Since we all know that increasing cache size is a diminishing
> > >returns game,
> <
> > Is it? LLC is getting bigger (and wider as core counts increase)
> > annually. The end game will be DRAM with single cycle latency making
> > cache irrelevent. Someday.
> <
> DRAM has stayed stubbornly at 20ns since 2000. You can run more
> data over the pins, but the banks inside have a fundamental timing
> that is going no where.

Worst case latency (page conflict) today as seen on DRAM device balls
is ~35-40ns. I think, back in 2000 it was over 50 ns.
It could have been better if standard DRAM was not heavily optimized for
density per $ 1st, bandwidth per pin 2nd, power 3rd and latency at best 4th..

It's not just theory. Here you can see what's possibly when low latency is
main objective:
https://www.micron.com/products/dram/rldram-memory/part-catalog

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, July 10, 2023 at 12:25:48=E2=80=AFPM UTC-5, Scott Lurndal wrote:
>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
>> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
>> >> John Levine wrote:=20
>>=20
>> >>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
>> >>> general purpose CPU chips I know with a cache were the 68030 in 1987=
>=20
>> >>> and i486 in 1989.=20
>> >>=20
>> >> That 486 had a combined code/data cache of just 8 KB, and that was sti=
>ll=20
>> >> enough to make a huge difference:=20
>> >=20
>> >Yup. Since we all know that increasing cache size is a diminishing=20
>> >returns game,
><
>> Is it? LLC is getting bigger (and wider as core counts increase)=20
>> annually. The end game will be DRAM with single cycle latency making=20
>> cache irrelevent. Someday.
><
>DRAM has stayed stubbornly at 20ns since 2000. You can run more
>data over the pins, but the banks inside have a fundamental timing
>that is going no where.

I'm thinking more along the lines of newer technology, perhaps
nonvolatile like PCM or MRAM.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 7/10/2023 10:25 AM, Scott Lurndal wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:
>>>> John Levine wrote:
>>
>>>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>>>> and i486 in 1989.
>>>>
>>>> That 486 had a combined code/data cache of just 8 KB, and that was still
>>>> enough to make a huge difference:
>>>
>>> Yup. Since we all know that increasing cache size is a diminishing
>>> returns game,
>>
>> Is it?
>
>Yes. See below.
>
>
>> LLC is getting bigger (and wider as core counts increase)
>> annually.
>
>While that is true, it doesn't contradict my point. Diminished returns
>are still better than no returns, and designers haven't come up with a
>better alternative use for the die space.

I'm not sure that they're yet diminished. Larger LLC has a big impact
on many common workloads.

>
>
>> The end game will be DRAM with single cycle latency making
>> cache irrelevent. Someday.
>
>Others with more hardware knowledge can chime in here, but I don't think
>so. Just the DRAM organization requiring RAS then CAS means two cycles
>even if there is no more internal latency, which is still a very tall order.

Ah, using the term 'DRAM' may not have been the best choice of word. Think
new technologies, perhaps non-volatile. PCM or MRAM were in vogue for a
few years, but have not come to fruition.

Michael S <already5chosen@yahoo.com> writes:
>On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
>> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
>> >> John Levine wrote:=20
>>=20
>> >>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
>> >>> general purpose CPU chips I know with a cache were the 68030 in 1987=
>=20
>> >>> and i486 in 1989.=20
>> >>=20
>> >> That 486 had a combined code/data cache of just 8 KB, and that was sti=
>ll=20
>> >> enough to make a huge difference:=20
>> >=20
>> >Yup. Since we all know that increasing cache size is a diminishing=20
>> >returns game,
>> Is it? LLC is getting bigger (and wider as core counts increase)=20
>> annually.=20
>
>Look at LLC per core.
>Intel Penryn (2007) had 3 MB of L2 per core.
>AMD Zen4 (2022) has 4 MB of L3 per core.
>So 30% increase in 15 years. And even that moderate increase is not free
>in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
>more like 6-7 ns.

Now also factor in the increase in core counts (> 100).

>
>> The end game will be DRAM with single cycle latency making=20
>> cache irrelevent. Someday.
>
>Do you predict that your future CPUs will have clock frequency =3D 25-30 MH=

I predict that some new memory technology will usurp DRAM. I should not have
used the term DRAM; instead:

The end game will be memory with a single cycle latency..

On 7/10/2023 1:15 PM, Scott Lurndal wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> On 7/10/2023 10:25 AM, Scott Lurndal wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:
>>>>> John Levine wrote:
>>>
>>>>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>>>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>>>>> and i486 in 1989.
>>>>>
>>>>> That 486 had a combined code/data cache of just 8 KB, and that was still
>>>>> enough to make a huge difference:
>>>>
>>>> Yup. Since we all know that increasing cache size is a diminishing
>>>> returns game,
>>>
>>> Is it?
>>
>> Yes. See below.
>>
>>
>>> LLC is getting bigger (and wider as core counts increase)
>>> annually.
>>
>> While that is true, it doesn't contradict my point. Diminished returns
>> are still better than no returns, and designers haven't come up with a
>> better alternative use for the die space.
>
> I'm not sure that they're yet diminished. Larger LLC has a big impact
> on many common workloads.

Again, perhaps true, but doesn't contradict my point. I am not saying
that more cache isn't better. I am saying that, for example if you have
X amount of cache, going from X to 2X, buys you a bigger increase in
performance than going from 2X to 3X. Yes, 3X is better, just not as
much better as the first increment.

>>> The end game will be DRAM with single cycle latency making
>>> cache irrelevent. Someday.
>>
>> Others with more hardware knowledge can chime in here, but I don't think
>> so. Just the DRAM organization requiring RAS then CAS means two cycles
>> even if there is no more internal latency, which is still a very tall order.
>
> Ah, using the term 'DRAM' may not have been the best choice of word. Think
> new technologies, perhaps non-volatile. PCM or MRAM were in vogue for a
> few years, but have not come to fruition.

OK, got ya. Yes, there is always hope for new technologies.

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

On Monday, July 10, 2023 at 11:16:50 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
> >> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
> >> >> John Levine wrote:=20
> >>=20
> >> >>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
> >> >>> general purpose CPU chips I know with a cache were the 68030 in 1987=
> >=20
> >> >>> and i486 in 1989.=20
> >> >>=20
> >> >> That 486 had a combined code/data cache of just 8 KB, and that was sti=
> >ll=20
> >> >> enough to make a huge difference:=20
> >> >=20
> >> >Yup. Since we all know that increasing cache size is a diminishing=20
> >> >returns game,
> >> Is it? LLC is getting bigger (and wider as core counts increase)=20
> >> annually.=20
> >
> >Look at LLC per core.
> >Intel Penryn (2007) had 3 MB of L2 per core.
> >AMD Zen4 (2022) has 4 MB of L3 per core.
> >So 30% increase in 15 years. And even that moderate increase is not free
> >in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
> >more like 6-7 ns.
> Now also factor in the increase in core counts (> 100).
>
> >
> >> The end game will be DRAM with single cycle latency making=20
> >> cache irrelevent. Someday.
> >
> >Do you predict that your future CPUs will have clock frequency =3D 25-30 MH=
>
> I predict that some new memory technology will usurp DRAM. I should not have
> used the term DRAM; instead:
>
> The end game will be memory with a single cycle latency..

Assuming that memory is on separate package, even if memory array itself has
infinite speed, but you want a bandwidth per pin comparable with DDR5 + ability
to share the bus between 4 memory devices, the latency would not be better than
8-10 ns.

On Monday, July 10, 2023 at 11:16:50 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
> >> >On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
> >> >> John Levine wrote:=20
> >>=20
> >> >>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
> >> >>> general purpose CPU chips I know with a cache were the 68030 in 1987=
> >=20
> >> >>> and i486 in 1989.=20
> >> >>=20
> >> >> That 486 had a combined code/data cache of just 8 KB, and that was sti=
> >ll=20
> >> >> enough to make a huge difference:=20
> >> >=20
> >> >Yup. Since we all know that increasing cache size is a diminishing=20
> >> >returns game,
> >> Is it? LLC is getting bigger (and wider as core counts increase)=20
> >> annually.=20
> >
> >Look at LLC per core.
> >Intel Penryn (2007) had 3 MB of L2 per core.
> >AMD Zen4 (2022) has 4 MB of L3 per core.
> >So 30% increase in 15 years. And even that moderate increase is not free
> >in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
> >more like 6-7 ns.
> Now also factor in the increase in core counts (> 100).
>

In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
The rest of increase in core count is due to MCM packaging rather than
Moore's law.

In Intel's case, they had 28-core die in commercial product back in 2017.
I think, their latest and greatest Xeon has only 15 cores per die plus 1 spare.
Almost 2x *decrease* in 6 years.

> >
> >> The end game will be DRAM with single cycle latency making=20
> >> cache irrelevent. Someday.
> >
> >Do you predict that your future CPUs will have clock frequency =3D 25-30 MH=
>
> I predict that some new memory technology will usurp DRAM. I should not have
> used the term DRAM; instead:
>
> The end game will be memory with a single cycle latency..

On Monday, July 10, 2023 at 11:15:14 PM UTC+3, Scott Lurndal wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >On 7/10/2023 10:25 AM, Scott Lurndal wrote:
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> >>>> John Levine wrote:
> >>
> >>>>> Cache? What's a cache? The PC was shipped in 1981 and the first
> >>>>> general purpose CPU chips I know with a cache were the 68030 in 1987
> >>>>> and i486 in 1989.
> >>>>
> >>>> That 486 had a combined code/data cache of just 8 KB, and that was still
> >>>> enough to make a huge difference:
> >>>
> >>> Yup. Since we all know that increasing cache size is a diminishing
> >>> returns game,
> >>
> >> Is it?
> >
> >Yes. See below.
> >
> >
> >> LLC is getting bigger (and wider as core counts increase)
> >> annually.
> >
> >While that is true, it doesn't contradict my point. Diminished returns
> >are still better than no returns, and designers haven't come up with a
> >better alternative use for the die space.
> I'm not sure that they're yet diminished. Larger LLC has a big impact
> on many common workloads.
> >
> >
> >> The end game will be DRAM with single cycle latency making
> >> cache irrelevent. Someday.
> >
> >Others with more hardware knowledge can chime in here, but I don't think
> >so. Just the DRAM organization requiring RAS then CAS means two cycles
> >even if there is no more internal latency, which is still a very tall order.
> Ah, using the term 'DRAM' may not have been the best choice of word. Think
> new technologies, perhaps non-volatile.

Non-volatile is pretty much guaranteed to have higher write energy per bit.
Also, so far most successful non-volatile technologies had limited endurance.
1e7 writes per life time at best, often much much less. Which means a need
for wire levelling. Which means a layer of re-map. Which means even higher
latency.

> PCM or MRAM were in vogue for a
> few years, but have not come to fruition.

Exactly.
The most promising and even a little commercially successful PCM
tech (Intel/Micron 3D XPoint) is officially dead since exactly a year ago.

Brian G. Lucas <bagel99@gmail.com> schrieb:

> Yes, a 16-bit instruction word with 16 registers is possible. And yes,
> constants were a bit of a problem.
>
> See Motorola (then Freescale, then NXP) MCore. The Chinese licensed it
> and called it CCore. There is even a Linux port to it.
> I designed the original instruction set.

I've just looked at it, and you certainly had your work cut out for you
fitting that much functionality into 16 bits...

Did it pay off with respect to code density?

On Tuesday, July 11, 2023 at 10:03:32 AM UTC+3, Thomas Koenig wrote:
> Brian G. Lucas <bag...@gmail.com> schrieb:
> > Yes, a 16-bit instruction word with 16 registers is possible. And yes,
> > constants were a bit of a problem.
> >
> > See Motorola (then Freescale, then NXP) MCore. The Chinese licensed it
> > and called it CCore. There is even a Linux port to it.
> > I designed the original instruction set.
> I've just looked at it, and you certainly had your work cut out for you
> fitting that much functionality into 16 bits...
>
> Did it pay off with respect to code density?

It looks like MCore lost internal battle within Freescale to e200 family.
e200 tries to achieve competitive code density by means of VLE variant of
PPC32 ISA.
The outcome, of course, does not mean that e200 code density is as good
as MCore, but does mean that it is (was) good enough for a target market.

John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>
>>> Cost !!
>>> 8088 was in a smaller package than 68008.
>
> No, it was definitely availability.
>
>> 8088 was apparently DIP40 with multiplexed Address/Data lines.
>>
>> Looks like the main difference here between 8086 and 8088 was that 8086
>> had 16 pins being multiplexed Address/Data, and 8088 had 8 pins multiplexed.
>
> That's it. Otherwise they were the same.

---------------------------^were nearly the same.

As I mentioned previously, the amount of prefetch code buffer space was
different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to remember
since both versions had both an 8 and a 6. :-)
>
> The 8089 I/O processor also had nearly the same pinout. Intel expected
> you to use a combination of them but the CPUs were good enough that
> people skipped the 8089s.
>
This did lead to some downstream issues with later cpus afair, mainly
because IBM also ignored the Intel recommended IRQ setup.

Terje

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

Michael S wrote:
> On Monday, July 10, 2023 at 11:16:50 PM UTC+3, Scott Lurndal wrote:
>> Michael S <already...@yahoo.com> writes:
>>> On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
>>>>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
>>>>>> John Levine wrote:=20
>>>> =20
>>>>>>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
>>>>>>> general purpose CPU chips I know with a cache were the 68030 in 1987=
>>> =20
>>>>>>> and i486 in 1989.=20
>>>>>> =20
>>>>>> That 486 had a combined code/data cache of just 8 KB, and that was sti=
>>> ll=20
>>>>>> enough to make a huge difference:=20
>>>>> =20
>>>>> Yup. Since we all know that increasing cache size is a diminishing=20
>>>>> returns game,
>>>> Is it? LLC is getting bigger (and wider as core counts increase)=20
>>>> annually.=20
>>>
>>> Look at LLC per core.
>>> Intel Penryn (2007) had 3 MB of L2 per core.
>>> AMD Zen4 (2022) has 4 MB of L3 per core.
>>> So 30% increase in 15 years. And even that moderate increase is not free
>>> in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
>>> more like 6-7 ns.
>> Now also factor in the increase in core counts (> 100).
>>
>
> In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
> The rest of increase in core count is due to MCM packaging rather than
> Moore's law.
>
> In Intel's case, they had 28-core die in commercial product back in 2017.
> I think, their latest and greatest Xeon has only 15 cores per die plus 1 spare.
> Almost 2x *decrease* in 6 years.

Unless you ignore the Larrabee descendants, since they started out with
~60 cores 15 years ago.

Terje

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

Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
>>>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
>>>>> John Levine wrote:=20
>>> =20
>>>>>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
>>>>>> general purpose CPU chips I know with a cache were the 68030 in 1987=
>> =20
>>>>>> and i486 in 1989.=20
>>>>> =20
>>>>> That 486 had a combined code/data cache of just 8 KB, and that was sti=
>> ll=20
>>>>> enough to make a huge difference:=20
>>>> =20
>>>> Yup. Since we all know that increasing cache size is a diminishing=20
>>>> returns game,
>>> Is it? LLC is getting bigger (and wider as core counts increase)=20
>>> annually.=20
>>
>> Look at LLC per core.
>> Intel Penryn (2007) had 3 MB of L2 per core.
>> AMD Zen4 (2022) has 4 MB of L3 per core.
>> So 30% increase in 15 years. And even that moderate increase is not free
>> in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
>> more like 6-7 ns.
>
> Now also factor in the increase in core counts (> 100).
>
>>
>>> The end game will be DRAM with single cycle latency making=20
>>> cache irrelevent. Someday.
>>
>> Do you predict that your future CPUs will have clock frequency =3D 25-30 MH=
>
> I predict that some new memory technology will usurp DRAM. I should not have
> used the term DRAM; instead:
>
> The end game will be memory with a single cycle latency..

You wish!

There is simply no way to reconcile the need for longer wires in order
to address a _lot_ more memory, and the desire for single cycle access.

Afaik, even registers have issues with single-cycle access, it only
works due to pipelining and forwarding networks, and it is typically one
of the main speed paths on a modern core afaik?

Terje

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