BGB wrote:

> On 1/4/2024 9:09 AM, EricP wrote:
>> MitchAlsup wrote:
>>> BGB wrote:
>>>
>>>> Also made an effort to avoid anything which lacks prior art from at
>>>> least 20 years ago.
>>>
>>> Yes, over my 35+ year career I was exposed to 10s of thousands of
>>> patents.
>>> I tried rigorously to avoid the ones still in effect. I did borrow a few
>>> of my patents knowing their expiration dates. I also have a clean
>>> record of my <potential> inventions identifying when they were first
>>> conceived.
>>
>> IANAL
>>
>> With the rule change from "first to invent" to "first to file"
>> is having a date record of inventions any use?
>>
>> There is also the question of whether writing about something
>> on the internet counts as "publication" and might block patenting.
>>
>> A quicky search finds this:
>>
>> How Publications Affect Patentability
>> https://www.utoledo.edu/research/TechTransfer/Publish_and_Perish.html
>>
>> "The Internet: A message describing an invention on a web site or to a
>> public newsgroup will be considered as published on the day prior to
>> the posting"
>>

> My concern was more with the possibility of lawyers being jerks...

I can alleviate you concerns--they are.

> But, if one mostly sticks to design features that were already in use
> 20-30 years ago; there isn't much the lawyers can do...

And written in books or published in papers.

> Granted, one could argue that this does not cover every possible way in
> which these features could be combined, which is a possible area for
> concern.

> Though, for the most part, it seems that the "enforcement" is mostly
> used against either direct re-implementations of a patented technology,
> or against popular common-use technologies that can be "interpreted" to
> somehow infringe on a patent (even if the artifact described is often
> almost entirely different), rather than going after ex-nihilo hobby
> projects or similar.

Also note: if you are not making money by using something claimed in their
patent, they can sue but they cannot get any money. So, it is not worth
their time.....

> ....

On Thu, 04 Jan 2024 19:00:46 +0000, MitchAlsup wrote:

> I would really like MS to go back to windows 7 {last one I liked}.....

Finally, something we both agree on!

John Savard

Quadibloc <quadibloc@servername.invalid> writes:
>On Thu, 04 Jan 2024 19:00:46 +0000, MitchAlsup wrote:
>
>> I would really like MS to go back to windows 7 {last one I liked}.....
>
>Finally, something we both agree on!

Really, there has never been an usable Windows release.....

Unix forever! :-)

On Fri, 05 Jan 2024 14:25:27 +0000, Scott Lurndal wrote:
> Quadibloc <quadibloc@servername.invalid> writes:
>>On Thu, 04 Jan 2024 19:00:46 +0000, MitchAlsup wrote:

>>> I would really like MS to go back to windows 7 {last one I liked}.....

>>Finally, something we both agree on!

> Really, there has never been an usable Windows release.....

> Unix forever! :-)

It certainly is true that Linux has some major advantages. People
have had to put up with Windows, though, because some software is
only available for it.

John Savard

On Fri, 24 Nov 2023 03:11:17 +0000, MitchAlsup wrote:

> This is headed in the right direction. Make context switching something
> easy to pull off.

Oh, dear. You've just given me an evil idea.

On a System/360, context switching wasn't too bad. You just save
and restore the 16 general registers and the floating-point
registers.

On a more recent CPU, you might have to save and restore the
general registers, the floating-point registers, and the SIMD
registers.

On Concertina II, in addition to 32 integer registers, 32
floating-point registers, 16 SIMD registers, there are also
eight 64-element vector registers!

On the Texas Instruments TI 9900, there were 16 general registers
which were 16 bits long - but they were in memory, so context
switching was _really_ fast, you just saved and restored the
workspace pointer!

So the evil idea is...

while the CPU does have real registers in order to run at an
acceptable speed, allow it to also run in "slow mode" with
a workspace pointer and all the registers in RAM!

To make it slightly less evil, have the address in the
workspace pointer point into an on-chip static RAM instead
of extenal DRAM.

And have a second bank of real registers, into which the
register contents are gradually migrated as the program
is running - I think the 990/10 or at least the 990/12
actually used the technique of gradually migrating registers
in RAM into real registers in the CPU for better performance,
so that's not new.

Of course, code that doesn't know it's running in slow mode
will wastefully save and restore those in-memory registers,
so the feature would be primarily recommended for use with
special programs specifically designed for coping with things
like a high frequency of interrupts.

John Savard

On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:

> To make it slightly less evil, have the address in the workspace pointer
> point into an on-chip static RAM instead of extenal DRAM.

And then when you're switching from one virtualized operating
system to another, you have to do a "big context switch" where
you save and restore all the registers _and_ that on-chip
static RAM!

However, that can be cured. Since the feature is specifically
*for* stuff like data acquisition programs that run straight on
the hardware, treat it as an optional feature... which is *not
included* on any virtual machine.

Which is great, of course, unless you would like to virtualize
some data acquisition software for purposes of debugging. So
instead a more approprate response is perhaps to _allow_
including fast context switching through slow mode in virtual
machines... with a warning in the manual that this is only
to be done when necessary, as it comes with a huge performance
hit.

John Savard

On 1/4/2024 7:04 AM, Anton Ertl wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> surely people don't view the Itanium as being a RISC?
>>
>>> It has a lot of RISC characteristics, in particular, it's a
>>> load/store architecture with a large number of general-purpose
>>> registers (and for the other registers, there are also many of
>>> them, avoiding the register allocation problems that compilers
>>> tend to have with unique registers). In 1999 I wrote
>>> <http://www.complang.tuwien.ac.at/anton/ia-64-1999.txt>:
>>>
>>> |It's basically a RISC with lots of special features:
>>
>> I think the same description could be said of the IBM System/360.
>> I don't think of System/360 as a RISC, even if a subset of it
>> might be.
>
> And I don't think so, either. That's because some of the features
> that the IBM 801 left away are non-RISC features, such as the EDIT
> instruction. OTOH, none of the special features of IA-64 are
> particularly non-RISCy, and indeed, it's implementations implemented
> the instructions without microcode (AFAIK) and typically with a
> single-cycle issue rate per functional unit. What makes you think it
> is not a RISC?
>

Most obvious departure:
Most RISC's have 32-bit instruction words or similar.

IA64 had 3 instructions per 128-bit block, with some bits indicating how
to process the other instructions. Typically, the instructions in the
block would execute in parallel rather than serial (so, would take a big
hit in code density if the code lacked sufficient ILP, as many of these
spots would hold NOPs).

If, say, one has 32-bit instructions which use a bit and may daisy chain
as needed to form bundles, then one avoids taking a massive hit to code
density.

> - anton

Quadibloc wrote:

> On Fri, 24 Nov 2023 03:11:17 +0000, MitchAlsup wrote:

>> This is headed in the right direction. Make context switching something
>> easy to pull off.

> Oh, dear. You've just given me an evil idea.

> On a System/360, context switching wasn't too bad. You just save
> and restore the 16 general registers and the floating-point
> registers.

> On a more recent CPU, you might have to save and restore the
> general registers, the floating-point registers, and the SIMD
> registers.

> On Concertina II, in addition to 32 integer registers, 32
> floating-point registers, 16 SIMD registers, there are also
> eight 64-element vector registers!

One of the reasons My 66000 only has 32 GPRs is context switch time.
5 cache lines go out, 5 cache lines come in, presto you are in an
entirely different context--with no more smarts added than a cache.

> On the Texas Instruments TI 9900, there were 16 general registers
> which were 16 bits long - but they were in memory, so context
> switching was _really_ fast, you just saved and restored the
> workspace pointer!

Remembering where those 5 cache lines came from means you can
deposit the data where it belongs long term rather than on
the system/kernel stack.

> So the evil idea is...

> while the CPU does have real registers in order to run at an
> acceptable speed, allow it to also run in "slow mode" with
> a workspace pointer and all the registers in RAM!

Just treat the registers as if they were a cache from an area
in memory no other thread will be accessing.

> To make it slightly less evil, have the address in the
> workspace pointer point into an on-chip static RAM instead
> of extenal DRAM.

Unless you can get all levels of privilege in that RAM you
just added complexity and complexity management to context
switch.

Quadibloc wrote:

> On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:

>> To make it slightly less evil, have the address in the workspace pointer
>> point into an on-chip static RAM instead of extenal DRAM.

> And then when you're switching from one virtualized operating
> system to another, you have to do a "big context switch" where
> you save and restore all the registers _and_ that on-chip
> static RAM!

I submit the proper place for memory resident register files and
thread-state is in DRAM. Then, writing a single control register
can switch between user threads, and writing 2 control registers
switches between GuestOSs,.....

> However, that can be cured.

Yes, by placing the data in the right place at the beginning.

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>>>
>>>> - The branch predictor tables be separated by user and super mode,
>>>> and that OS's be advised to purge the user mode tables on thread switch.
>>> Now that's an expensive approach in both silicon and performance: The
>>> branch predictor, one of the biggest parts of a core would need to
>>> become twice as big to get the same accuracy for a program that spends
>>> almost all of its time in user mode, or almost all of its time in
>>> system mode. And a user-level program would still be slowed down a
>>> lot every time there is a thread switch.

That was the simplest form. A more sophisticated version could have
a 2 or 3 bit tag like an ASID on each branch predictor entry.
Tag 0 is for super mode, others are for the most recent 3 or 7 processes
run on this core. If a lookup hits on an entry with a different tag
then the entry is set to its uninitialized state.

Though I'm not sure how this could work with the return stack predictor.
Probably have to keep 4 or 8 copies of it.

>> Why would the branch predictions from a different thread/process
>> be helpful to your thread?
>
> The typical scenario where a thread can benefit from not flushing the
> branch predictor is when there is a switch to a different thread for a
> short while and then a switch back.
>
> However, there are also scenarios where threads benefit from the
> branch predictions collected in a different thread:
>
> * if the thread is in the same process, and processes the same code or
> the same data.

Yes, only flush if the new thread is in a different process.

> * if the thread is in a different process, and executes a common
> library (e.g., libc), or works on the same data (e.g., in a pipe).

IMO this "optimization" is not worth the security hole.

>> Retaining predictions across security domains *IS* the problem
>> because it allows an attacker to influence/control a victim.
>> The side channel leaks, while also important, are just a display mechanism.
>> But with no control over a victim an attacker can make no use of
>> side channels to display secrets.
>
> Spectre can be fixed by either preventing the side channel from the
> speculative to the committed state (the approach I suggest), or by
> preventing speculation (what the people who want to turn off
> speculation suggest).
>
> You suggest that erasing the branch predictor on thread switches is
> just as good as preventing speculation. But it isn't. Even without
> training, as long as there is speculation and the side channel from
> the speculative to the committed world, some data will be leaked. Ok,
> you may be tempted to rely on your luck that it's not sensitive data,
> but that does not appear to be a very trustworthy approach.

I would also rely on the NoSpeculate branch hint to stall branches
that check array bounds.

> And that's especially the case because the attacker may be able to
> help luck in the attacker's direction by passing data to the victim
> process that results in training the branch predictor of the victim in
> a specific way. E.g., a PDF document processed by a browser will
> result in a lot of branches being taken in a certain way, which will
> train the branch predictor in a certain way.
>
>
>>>> - I have an extensive set of conditional trap instructions intended for
>>>> bounds checks, asserts, etc. In OoO a load or store following a
>>>> bounds check might execute before the check exception was delivered.
>>>> These trap instructions could have an optional NoSpeculate flag
>>>> which again stalls the Dispatcher and essentially single steps just
>>>> that instruction until the test condition resolves.
>>> Also very expensive for programs (programming languages) that use
>>> these instructions; speculative load hardening (SLH), which prevents
>>> Spectre v1 by turning the control dependence on the bounds check into
>>> a data dependence costs a factore 2.3-2.5 (depending on the SLH
>>> variant) on the SPEC programs, and I expect your bounds-check trap
>>> instructions to be at least as expensive.
>> I'm not sure - it depends on the frequency of occurence and
>> the latency between Dispatch and branch condition resolution.
>>
>> Based on nothing, I'm assuming both to be small :-)
>
> The main reason why OoO so vastly outperforms in-order for
> general-purpose code is that execution does not have to wait for the
> branches to be resolved; this is reflected in the size of the
> outstanding branches, which is, e.g., 128 for the Golden Cove <
> https://chipsandcheese.com/2021/12/21/gracemont-revenge-of-the-atom-cores/#gracemont-s-out-of-order-engine>
> (look for "Branch Order Buffer"). If you throw in one NoSpeculate
> branch, this reduces this number to 0 for this branch. And given the
> number of loads in a program, you probably have to make most branches
> "NoSpeculate" to be safe. So you fall back to close to in-order
> performance.

BTW near as I can tell the "Branch Order Buffer" is just Intel's name
for what others call the register file rename checkpoint.

As I saw it, the NoSpeculate hint only stalls to wait for its branch,
not all pending branches. The idea being that most branches are not for
array bounds checks so don't need guarding, and for those that are bounds
checks the array access LD's and ST's likely immediately follow.
But it could also be used to eliminate timing variations in crypto loops.

But yes, it does stall all following instructions.
This was intended as a simple option that user or compilers can apply.
To guard just a subset of the following instructions would require
a mechanism like full predication which would be much more expensive.

EricP wrote:

> Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> Anton Ertl wrote:
>>>>>
>>>>> - The branch predictor tables be separated by user and super mode,
>>>>> and that OS's be advised to purge the user mode tables on thread switch.
>>>> Now that's an expensive approach in both silicon and performance: The
>>>> branch predictor, one of the biggest parts of a core would need to
>>>> become twice as big to get the same accuracy for a program that spends
>>>> almost all of its time in user mode, or almost all of its time in
>>>> system mode. And a user-level program would still be slowed down a
>>>> lot every time there is a thread switch.

> That was the simplest form. A more sophisticated version could have
> a 2 or 3 bit tag like an ASID on each branch predictor entry.

Which halves the number of entries you can store or worse. Remember
branch prediction states are un-tagged 2-bit saturating counters.

> Tag 0 is for super mode, others are for the most recent 3 or 7 processes
> run on this core. If a lookup hits on an entry with a different tag
> then the entry is set to its uninitialized state.

> Though I'm not sure how this could work with the return stack predictor.
> Probably have to keep 4 or 8 copies of it.

>>> Why would the branch predictions from a different thread/process
>>> be helpful to your thread?
>>
>> The typical scenario where a thread can benefit from not flushing the
>> branch predictor is when there is a switch to a different thread for a
>> short while and then a switch back.
>>
>> However, there are also scenarios where threads benefit from the
>> branch predictions collected in a different thread:
>>
>> * if the thread is in the same process, and processes the same code or
>> the same data.

> Yes, only flush if the new thread is in a different process.

>> * if the thread is in a different process, and executes a common
>> library (e.g., libc), or works on the same data (e.g., in a pipe).

> IMO this "optimization" is not worth the security hole.

>>> Retaining predictions across security domains *IS* the problem
>>> because it allows an attacker to influence/control a victim.
>>> The side channel leaks, while also important, are just a display mechanism.
>>> But with no control over a victim an attacker can make no use of
>>> side channels to display secrets.
>>
>> Spectre can be fixed by either preventing the side channel from the
>> speculative to the committed state (the approach I suggest), or by
>> preventing speculation (what the people who want to turn off
>> speculation suggest).
>>
>> You suggest that erasing the branch predictor on thread switches is
>> just as good as preventing speculation. But it isn't. Even without
>> training, as long as there is speculation and the side channel from
>> the speculative to the committed world, some data will be leaked. Ok,
>> you may be tempted to rely on your luck that it's not sensitive data,
>> but that does not appear to be a very trustworthy approach.

> I would also rely on the NoSpeculate branch hint to stall branches
> that check array bounds.

My 66000 PREDication does not use the branch prediction tables.

mitchalsup@aol.com (MitchAlsup) writes:
>Quadibloc wrote:
>
>> On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:
>
>>> To make it slightly less evil, have the address in the workspace pointer
>>> point into an on-chip static RAM instead of extenal DRAM.
>
>> And then when you're switching from one virtualized operating
>> system to another, you have to do a "big context switch" where
>> you save and restore all the registers _and_ that on-chip
>> static RAM!
>
>I submit the proper place for memory resident register files and
>thread-state is in DRAM. Then, writing a single control register
>can switch between user threads, and writing 2 control registers
>switches between GuestOSs,.....

Doesn't this cost at least one cache line in L1?

Intel and AMD do this for the virtual machine state, but there's
an access cost to read from dram. ARM64 keeps all the VM
state in a small number of system registers that the HV can
swap as necessary.

>
>> However, that can be cured.
>
>Yes, by placing the data in the right place at the beginning.

Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup) writes:
>>Quadibloc wrote:
>>
>>> On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:
>>
>>>> To make it slightly less evil, have the address in the workspace pointer
>>>> point into an on-chip static RAM instead of extenal DRAM.
>>
>>> And then when you're switching from one virtualized operating
>>> system to another, you have to do a "big context switch" where
>>> you save and restore all the registers _and_ that on-chip
>>> static RAM!
>>
>>I submit the proper place for memory resident register files and
>>thread-state is in DRAM. Then, writing a single control register
>>can switch between user threads, and writing 2 control registers
>>switches between GuestOSs,.....

> Doesn't this cost at least one cache line in L1?

No, because HW is doing the reads and writes, the data streams around
the L1D. That is, it may have to pass by L1 on the way in, and it can
pass by L1 on the way out, it does not interact with the footprint of
data or inst already in L1. {I am leaning on not storing in L2 on the
way out but in L3}. Inbound access probe caches so if data is present
it gets used. Outbound accesses probe caches and be written on hits.

One can in principle bypass the caches on the way in and on the way out.
DRAM <-> core registers
or even
DRAM -> core registers -> DRAM
where newly arriving registers push out the existing registers.

You are not expecting the 5 to be needed any time soon.

> Intel and AMD do this for the virtual machine state, but there's
> an access cost to read from dram.

The important point about using the word DRAM is that this 5-cache
line structure has a fixed PA. It can be cached anywhere and that
when that thread in not in control all its thread-state appears to
be is in that PA.

> ARM64 keeps all the VM
> state in a small number of system registers that the HV can
> swap as necessary.

My 66000 memory maps all control registers so even a remote CPU
can diddle with stuff a local CPU will see instantaneously
{mainly for debug of dead core}.

mitchalsup@aol.com (MitchAlsup) writes:
>Scott Lurndal wrote:

>
>> ARM64 keeps all the VM
>> state in a small number of system registers that the HV can
>> swap as necessary.
>
>My 66000 memory maps all control registers so even a remote CPU
>can diddle with stuff a local CPU will see instantaneously
>{mainly for debug of dead core}.

ARM64 cores have a similar feature.

On Fri, 05 Jan 2024 19:49:18 +0000, MitchAlsup wrote:
> Quadibloc wrote:
>> On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:

>>> To make it slightly less evil, have the address in the workspace
>>> pointer point into an on-chip static RAM instead of extenal DRAM.

>> And then when you're switching from one virtualized operating system to
>> another, you have to do a "big context switch" where you save and
>> restore all the registers _and_ that on-chip static RAM!

> I submit the proper place for memory resident register files and
> thread-state is in DRAM. Then, writing a single control register can
> switch between user threads, and writing 2 control registers switches
> between GuestOSs,.....

That would certainly make my "evil idea" less evil.

But, at first glance, that seems like something that
couldn't possibly be true. Registers are in constant
use by the processor, so accessing them should be very
fast. DRAM is slow!

Of course, though, a little bit of context shows that
you're not as badly wrong as you might seem at first
glance. Any computer these days with any pretensions
to efficiency has cache.

Oops: I missed reading "memory-resident" above; you did
not claim that _all_ register files belong in RAM, just
that my idea of having a special internal memory to allow
putting registers in memory was a bad one (which I won't
try to deny).

John Savard

On Fri, 05 Jan 2024 23:15:21 +0000, MitchAlsup wrote:

> My 66000 memory maps all control registers so even a remote CPU can
> diddle with stuff a local CPU will see instantaneously {mainly for debug
> of dead core}.

Oh, darn. I was going to save money by not providing proper cache
coherency hardware in implementations of Concertina II, but that
means I couldn't provide this useful feature!

Just kidding... sort of.

Mapping control registers to RAM is something I would never have
thought of, but I would indeed put pins on the package, the function
of which would be openly documented, to allow accessing chip internals.

My perverted purpose in doing so, though, was not so much for legitimate
debugging as to permit my chips to be used in retrocomputing toys...

A computer with a *real front panel* just like in the old days, not
just one like on the Altair that only handles the external memory bus!

As for cache coherency... well, of course that has to be supported
for a computer to actually work the way it's supposed to without
error. However, the way I would handle it is like this:

The CPU only bothers about cache coherency for cached data from
memory that has been _explicitly marked as shared_. So the
CPUs connected to the same memory have a message bus between them;
when one requests some memory to be shared, it sends a message
out about that, and doesn't use that memory until it gets acknowledged;
_then_ the CPUs that are sharing a certain area of memory notify
each other when they write to that area of memory.

The CPUs have to be told - they don't try to keep track of everything
anyone else might be doing on the bus.

However, I haven't really thought through this aspect of CPU chip
design. Since a microprocessor needs to handle the full speed of the
memory bus in order to talk to memory, possibly bus monitoring is
simpler than a conversational protocol handling only the memory that
"needs" to be monitored.

Come to think of it, though, perhaps a CPU needs to be able to do this
both ways - bus monitoring for normal multi-CPU motherboards, and a
conversational protocol so the chips can also be used in NUMA systems.

John Savard

Quadibloc wrote:

> On Fri, 05 Jan 2024 19:49:18 +0000, MitchAlsup wrote:
>> Quadibloc wrote:
>>> On Fri, 05 Jan 2024 15:18:46 +0000, Quadibloc wrote:

>>>> To make it slightly less evil, have the address in the workspace
>>>> pointer point into an on-chip static RAM instead of extenal DRAM.

>>> And then when you're switching from one virtualized operating system to
>>> another, you have to do a "big context switch" where you save and
>>> restore all the registers _and_ that on-chip static RAM!

>> I submit the proper place for memory resident register files and
>> thread-state is in DRAM. Then, writing a single control register can
>> switch between user threads, and writing 2 control registers switches
>> between GuestOSs,.....

> That would certainly make my "evil idea" less evil.

> But, at first glance, that seems like something that
> couldn't possibly be true. Registers are in constant
> use by the processor, so accessing them should be very
> fast. DRAM is slow!

Normally you are not as dense as you display tonight.

Registers have a PA but can be in a core or somewhere
in the memory hierarchy {not not config, not MMI/O }
and normal caching rules COULD apply.

> Of course, though, a little bit of context shows that
> you're not as badly wrong as you might seem at first
> glance. Any computer these days with any pretensions
> to efficiency has cache.

> Oops: I missed reading "memory-resident" above; you did
> not claim that _all_ register files belong in RAM, just
> that my idea of having a special internal memory to allow
> putting registers in memory was a bad one (which I won't
> try to deny).

All registers have a landing zone where they can be put back
or brought forth defined by a PA. HW is responsible for
obtaining new thread-state and of storing old thread-state.

BUT BECAUSE thread-state is completely defined by a single
PA, HW can change from one thread to another by writing
the control register holding that context PA.

> John Savard

Quadibloc wrote:

> On Fri, 05 Jan 2024 23:15:21 +0000, MitchAlsup wrote:

>> My 66000 memory maps all control registers so even a remote CPU can
>> diddle with stuff a local CPU will see instantaneously {mainly for debug
>> of dead core}.

> Oh, darn. I was going to save money by not providing proper cache
> coherency hardware in implementations of Concertina II, but that
> means I couldn't provide this useful feature!

> Just kidding... sort of.

> Mapping control registers to RAM is something I would never have
> thought of, but I would indeed put pins on the package, the function
> of which would be openly documented, to allow accessing chip internals.

> My perverted purpose in doing so, though, was not so much for legitimate
> debugging as to permit my chips to be used in retrocomputing toys...

> A computer with a *real front panel* just like in the old days, not
> just one like on the Altair that only handles the external memory bus!

> As for cache coherency... well, of course that has to be supported
> for a computer to actually work the way it's supposed to without
> error. However, the way I would handle it is like this:

> The CPU only bothers about cache coherency for cached data from
> memory that has been _explicitly marked as shared_.

So, shared instruction sections are marked exclusive ?!?
So, thread-local-storage is marked shared if a pointer to its cats
is constructed !?!
Can a Hypervisor share code sections with Guest OS ??
,...

Conversely, My 66000 allows one to map ROM (coherence and order free)
onto DRAM, to provide relief from coherence traffic.

> So the
> CPUs connected to the same memory have a message bus between them;
> when one requests some memory to be shared, it sends a message
> out about that, and doesn't use that memory until it gets acknowledged;
> _then_ the CPUs that are sharing a certain area of memory notify
> each other when they write to that area of memory.

> The CPUs have to be told - they don't try to keep track of everything
> anyone else might be doing on the bus.

But certainly, when writing a buffer in VA[k] to disk, the core caches
have to be snooped so the disk gets the correct data.

> However, I haven't really thought through this aspect of CPU chip
> design. Since a microprocessor needs to handle the full speed of the
> memory bus in order to talk to memory, possibly bus monitoring is
> simpler than a conversational protocol handling only the memory that
> "needs" to be monitored.

> Come to think of it, though, perhaps a CPU needs to be able to do this
> both ways - bus monitoring for normal multi-CPU motherboards, and a
> conversational protocol so the chips can also be used in NUMA systems.

> John Savard

On Sat, 06 Jan 2024 01:41:42 +0000, MitchAlsup wrote:
> Quadibloc wrote:

>> The CPU only bothers about cache coherency for cached data from memory
>> that has been _explicitly marked as shared_.

> So, shared instruction sections are marked exclusive ?!?
> So, thread-local-storage is marked shared if a pointer to its cats is
> constructed !?!
> Can a Hypervisor share code sections with Guest OS ??

Presumably, when I get around to designing this part of the hardware,
I would check on what industry-standard practice is. I may indeed
have failed to properly think some things through.

But I can still try to answer your questions, I think.

The first question:

Instruction sections aren't normally writeable. So cache coherency
becomes a given; it's only lost when you write. Presumably, then,
a shared instruction section would be...

part of the OS,

a shared library,

a permanently resident popular program (i.e. a FORTRAN compiler on
an ancient mainframe)

and these areas would have only been written to by the operating system.

So an OS thread would be its "owner", but other threads could read it.

Your second question:

The pointer can exist; the memory has to be readable only if the pointer
is actually used. And its marked shared if it's used for writing as well
as reading.

Your third question:

At first, I thought that this was something you would never want to do.

But actually, it's quite common: there might be multiple instances of
one particular guest OS running, and so one might as well start them off
with all permanently resident parts of the OS loaded - and that memory
might as well be shared by all the instances (and, initially, at least,
by the parent hypervisor as well) to avoid duplication.

Stuff that is only shared for reading isn't a coherency issue.

>> The CPUs have to be told - they don't try to keep track of everything
>> anyone else might be doing on the bus.

> But certainly, when writing a buffer in VA[k] to disk, the core caches
> have to be snooped so the disk gets the correct data.

If you've designated an area in memory to be a buffer for DMA...

then you need to treat it like video memory inside a video card.
Mark it non-cacheable. So I do _not_ expect DMA controllers to
have a cache snoop capability; as for the CPUs, I was thinking
in terms of them always broadcasting any changes to shared memory,
so it's always "push" and never a "pull" so that snoop would be
needed. But cache snoop is common, so I guess it reduces message
traffic for cache coherency, which means I'll need to study how
this is done some more.

But you have reminded me of something I had forgotten. I thought
that if the CPUs, because they have to work with the memory bus
at its full speed, can monitor every write to memory, and so
maintain cache coherency that way, as an option, even if that
wasn't my preferred option.

But unless you always and only have write-through caches, the
actual value of a location in memory can change before a hint
of that gets out to the bus. In the case where the CPUs talk
directly to each other about everything that happens in shared
memory, that isn't a problem - but if they were to just monitor
the bus without direct communication, they would miss recent
updates to shared memory.

Actually, even _with_ a write-through cache, there would still
be a certain slight delay of a few cycles in a write, which
would be entirely sufficient to cause occasional problems.

John Savard

On 1/4/2024 3:19 AM, Anton Ertl wrote:
> Quadibloc <quadibloc@servername.invalid> writes:
>> On Tue, 02 Jan 2024 20:41:07 +0000, MitchAlsup wrote:
>>
>>> 16-bit instructions take 3/4ths of the OpCode Map of RISC-V. If you
>>> dropped the compressed instructions, I can fit then entire My 66000 ISA
>>> into the vacated space.....
>>
>> Ouch! 16-bit instructions took up 1/4th of the opcode space of Concertina
>> II, and that turned out to be too much, and I had to drop them.
>>
>> But then, RISC-V was designed with little or no regard for code density,
>
> I think that the fact that they left 3/4ths of the encoding space to
> 16-bit instructions shows that they care quite a bit for encoding
> size. If they did not, they would not have the C extension (the
> 16-bit instructions) at all.
>
> How successful are they? Let's update my code-size measurements with
> current data.
>
> ARCHS="amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x"
> for i in $ARCHS; do
> wget http://ftp.at.debian.org/debian/pool/main/b/bash/bash_5.2.21-2_$i.deb
> wget http://ftp.at.debian.org/debian/pool/main/b/bash/bash_5.2.21-2+b1_$i.deb
> wget http://ftp.at.debian.org/debian/pool/main/g/grep/grep_3.11-4~exp1_$i.deb
> wget http://ftp.at.debian.org/debian/pool/main/g/gzip/gzip_1.12-1_$i.deb
> wget http://ftp.at.debian.org/debian/pool/main/g/gzip/gzip_1.12-1+b2_$i.deb
> done
> for i in $ARCHS; do
> for j in bash_5.2.21-2_$i.deb bash_5.2.21-2+b1_$i.deb grep_3.11-4~exp1_$i.deb gzip_1.12-1_$i.deb gzip_1.12-1+b2_$i.deb; do
> if test -f $j; then
> binary=bin/${j%%_*}
> if test "$binary" = "bin/grep"; then
> binary=usr/bin/grep
> fi
> ar x $j; tar xfJ data.tar.xz ./$binary; objdump -h $binary|awk --non-decimal-data '/[.]text/ {printf("%8d ","0x"$3)}'
> fi
> done
> echo $i
> done|sort -nk1
>
> This produces:
>
> bash grep gzip
> 595204 107636 46744 armhf
> 599832 101102 46898 riscv64
> 796501 144926 57729 amd64
> 829776 134784 56868 arm64
> 853892 152068 61124 i386
> 891128 158544 68500 armel
> 892688 168816 64664 s390x
> 1020720 170736 71088 mips64el
> 1168104 194900 83332 ppc64el
>
> So RV64GC beats every other 64-bit instruction set in code density by
> a wide margin and the code density is similar to the 32-bit ARM
> A32/T32 instruction set. Given this evidence, it seems to me that
> RV64GC (and it's basis RISC-V) was designed with a lot of
> consideration for code density.
>
> One difference between armhf and armel is that armhf uses T32/A32
> (Thumb2 instructions) while armel uses only A32 (fixed-width 32-bin
> instructions). This probably accounts the most for the size
> difference between armhf and armel.
>
> It's interesting that A32/T32 and RV64GC with their fixed-width base
> and compressed extension beat the variable-width AMD64, i386, and
> S390x by such a wide margin.
>
> In case of armhf vs i386, you cannot even make the legacy argument,
> because ARM A32 was designed at the same time as i386, and T32 only
> tacked on later; ok, you may consider i386 to be tacked on to the
> slightly older 8086 instruction set, but given that 8086 code does not
> work in an i386 binary unless you set some mode flags first, while A32
> code runs without setting a mode bit on an A32/T32-capable CPU, the
> situation is not quite the same.
>

I guess I can feel less bad about BJX2 losing to RV64IMA in terms of
code density...

I have tested, and as-is, "-Os" vs "-O2" makes very little difference
for XG2 Mode, as the main things it tweaked (such as register allocator
behavior) have very little effect on code size for XG2.

So, at present, for Doom:
RV64IMA, -O3 -ffunction-sections, 289K (*1) (GCC 12.2.0)
RV64IMA, -Os -ffunction-sections, 274K
BJX2, XG2, 341K
BJX2, Baseline, 293K (*2)

*1: My earlier testing showed a bigger number here, seems something is
different this time around...

*2: Though, this case is less valid, as Baseline mode is 16/32, and
RV64IMA is fixed-length 32-bit.

x86-64 (GCC 4.8.4, WSL), -O3 -ffunction-sections, 404K
x86-64 (GCC 4.8.4, WSL), -Os -ffunction-sections, 194K
x86-64 (MSVC 2022), /O2, 1019K
x86-64 (MSVC 2022), /Os, 1083K (*3)

Don't have any other builds handy at the moment...

*3: Though, this is less a "victory" over x86-64, so much as VS 2022
seemingly being unable to generate compact code.

Though, I guess it is a mystery if BJX2 could do better if I could
somehow eliminate a lot of the cases that result in needless MOV
instructions:
Passing arguments to functions;
Getting the return value from a function;
Copying register arguments into variables;
Type promotions or conversions;
...

Like, in terms of cycle use stats, reg-reg MOV is right up there with
Load/Store and Branch ops, beating out most of the other ALU ops (at
around 2% of the cycle budget).

But, it is a case of like, I am aware of the issue, but not currently
aware of a good way to fix it (as this issue results from the general
structure of the compiler logic, and how it manages things like local
variables and temporaries).

> - anton

Quadibloc <quadibloc@servername.invalid> schrieb:
> On Thu, 04 Jan 2024 04:32:42 -0800, Tim Rentsch wrote:
>> Quadibloc <quadibloc@servername.invalid> writes:
>>
>>> Yes, the PDP-8 did have a small and simple instruction set.
>>>
>>> But that is _not_ what the meaning of RISC is commonly understood to
>>> be.
>>
>> My comments about the PDP-8 and RISC were not about what the meaning of
>> RISC is comonly understood (or commonly misunderstood)
>> to be. Rather they are about the meaning of RISC as described by the
>> people who originally defined the term. Please see my longer response
>> to John Levine.
>
> I'm not sure how this helps you, because the original definition
> includes the current common understanding, being a superset of it.
>
> Current common understanding:
>
> All instructions the same length.

So, Power10, RISC-V and 32-bit ARM (which has Thumb) are not RISC.
Good to know.

> Load-store architecture.
> Relatively large register file (32 or more registers)

.... and the 801, the original ARM v2 (without Thumb) weren't,
either.

On Sat, 06 Jan 2024 09:01:02 +0000, Quadibloc wrote:

> Stuff that is only shared for reading isn't a coherency issue.

Ouch. Stuff that is only being read isn't a coherency issue.

But if even one CPU writes to an area of memory, with all the
other CPUs to which it is shared only reading, clearly when
those CPUs read, they may need to be sure of reading up-to-date
information when they read it.

Of course, though, if the read appears to have taken place
earlier than it actually did, something else would have to
have happened that contradicts that for there to be a real
inconsistency, but the additional interaction that could
lead to that could also be in the form of a read in the same
direction rather than a write in the other direction.

John Savard

MitchAlsup <mitchalsup@aol.com> schrieb:
> BGB wrote:
>
>> On 1/4/2024 9:09 AM, EricP wrote:
>>> MitchAlsup wrote:
>>>> BGB wrote:
>>>>
>>>>> Also made an effort to avoid anything which lacks prior art from at
>>>>> least 20 years ago.
>>>>
>>>> Yes, over my 35+ year career I was exposed to 10s of thousands of
>>>> patents.
>>>> I tried rigorously to avoid the ones still in effect. I did borrow a few
>>>> of my patents knowing their expiration dates. I also have a clean
>>>> record of my <potential> inventions identifying when they were first
>>>> conceived.
>>>
>>> IANAL
>>>
>>> With the rule change from "first to invent" to "first to file"
>>> is having a date record of inventions any use?
>>>
>>> There is also the question of whether writing about something
>>> on the internet counts as "publication" and might block patenting.
>>>
>>> A quicky search finds this:
>>>
>>> How Publications Affect Patentability
>>> https://www.utoledo.edu/research/TechTransfer/Publish_and_Perish.html
>>>
>>> "The Internet: A message describing an invention on a web site or to a
>>> public newsgroup will be considered as published on the day prior to
>>> the posting"
>>>
>
>> My concern was more with the possibility of lawyers being jerks...
>
> I can alleviate you concerns--they are.
>
>> But, if one mostly sticks to design features that were already in use
>> 20-30 years ago; there isn't much the lawyers can do...
>
> And written in books or published in papers.
>
>> Granted, one could argue that this does not cover every possible way in
>> which these features could be combined, which is a possible area for
>> concern.
>
>> Though, for the most part, it seems that the "enforcement" is mostly
>> used against either direct re-implementations of a patented technology,
>> or against popular common-use technologies that can be "interpreted" to
>> somehow infringe on a patent (even if the artifact described is often
>> almost entirely different), rather than going after ex-nihilo hobby
>> projects or similar.
>
> Also note: if you are not making money by using something claimed in their
> patent, they can sue but they cannot get any money. So, it is not worth
> their time.....

At least in Germany, there are exceptions to patent protectiion,
among them using a patent privately for non-commercial purposes
and doing research (commercial or otherwise) on the subject of
the patent (§ 11 Patentgesetz). The latter is very important if,
for example, people want to try out if what is claimed in the
patent actually works.

Not sure what the situation in the US is.

On Mon, 04 Dec 2023 20:03:47 +0000, MitchAlsup wrote:
> Quadibloc wrote:

>> Since out-of-order is so expensive in power and transistors, though, if
>> mitigations do exact a performance cost, then going to a simple CPU
>> that is not out-of-order might be a way to accept a loss of
>> performance, but gain big savings in power and die size, whereas
>> mitigations make those worse.
>
> 18 years ago, when I quit building CPUs professionally, GBOoO
> performance was 2× what an 1-wide IO could deliver. In those 18 years
> the CPU makers have gone from 2× to 3× performance while the execution
> window has grown from 48 to 300 instructions.
> Clearly an unsustainable µArchitectural direction.

Yes, the law of diminishing returns means that even if Moore's Law
still lives on, they can't go _much_ further in that direction.

But do they have any other directions they can go in to get more
performance?

We have heard of a few:

1) Switch to a new, faster, semiconductor material if it becomes
possible.

2) Add new instructions, so as to make some additional operations
faster. Better yet, put something like an FPGA in the CPU, so
the chip can do anything quickly!

3) If we can't make the processors faster, provide more of them.
This is being done - first they put two CPUs on a chip, then four,
and now we're seeing quite a few.

Since we don't yet _have_ a new, faster semiconductor material
we can use, and since single-thread performance is what is most
ardently desired because software tends to be largely serial...
taking out-of-order to extreme lengths, despite diminishing returns,
has continued to be the most attractive option. Yes, that will have
to come to an end, but before it does, it may go at least a little
further, to a point which will seem even more like wretched excess
to you and many others.

And this brings me to

4) Adopt a new ISA, based on a design that does much of what OoO
does without OoO, based on DSP designs using VLIW and so on. Then,
with that as a base, also apply OoO, and one should need _less
extreme_ OoO for the same performance. And get more performance
when reaching the same level of wretched excess as was tolerated
before.

My Concertina II, with its VLIW features, and even (optional)
instructions to use banks of 128 registers is an attempt to
show what such an ISA might look like. Or how about an OoO
implementation of the Itanium? Or even, after the Mill becomes
popular, a way might be figured out to apply OoO techniques
to implementing that design, however revolting the thought may
be to Ivan Godard and its other designers!

Thanks to the end of Dennard scaling, until a new semiconductor
material comes along, the pressure to find some way to increase
performance still more is likely to lead to many novel designs,
at least some of which will be weird and grotesque.

John Savard

Thomas Koenig <tkoenig@netcologne.de> writes:
>> All instructions the same length.
>
>So, Power10, RISC-V and 32-bit ARM (which has Thumb) are not RISC.
>Good to know.

RISC-V without the C extension would be, but the C extension would
make it non-RISC. Likewise ARM A32 would be, but A32/T32 would not.

Power has instructions that are not 32 bits in size? Since when?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>