On 5/30/23 5:28 AM, Anton Ertl wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
[snip]
>> I seem to recall that MIPS and PowerPC required a mode bit at
>> least to distinguish the 32-bit overflow from internal register
>> size overflow.
>
> What is "internal register size overflow"?

I was thinking that overflow would only be detected if overflowing
the physical register size. (I forgot that MIPS added DADD/DADDU
[and presumably similar for multiplication though multiplication
cannot overflow since the result, IIRC, goes to two special
purpose registers].)

By PowerPC defining a 32-bit mode, (if I am remembering correctly)
an addition instruction could set the (sticky) overflow bit based
on the 32-bit result.

> Looking at the MIPS ADD
> instruction, it is defined to trap on 32-bit overflow. If you want a
> overflow-trapping 64-bit addition, you use DADD. Likewise, ADDU
> (which does not trap) sign-extends the 32-bit result, and you use
> DADDU for a 64-bit non-trapping addition.
>
>> RV32 not being effectively a subset of RV64 is disappointing to me
>> (and I seem to recall reading that it was a result of historical
>> accident/not fulling thinking through the alternatives).
>
> I don't find any trace of an accident in the RISC-V Instruction Set
> Manual. And given that the people involved have ample knowledge of
> the area, the examples of several other architectures that have taken
> the step (e.g., MIPS), and have taken their time for defining the
> instruction set, and accident seems unlikely.
>
> So why did the RISC-V let ADD work on the full register width and add
> ADDW for 32-bit operation in RV64 rather than following MIPS' example?
> One theory I had was that it produces a better compressed instruction
> set; however, the difference is small: C.ADD supports 32 registers per
> register operand, C.ADDW supports 8, and the difference between C.ADDI
> and C.ADDIW is even smaller.
>
> OTOH, the advantage of being able to run RV32 programs on RV64
> hardware is small, and if you want to build hardware that supports
> running both, the cost of a mode bit is probably small, too.
>
>> Such is
>> probably not the most significant deficiency in the ISA design or
>> in the development and standardization process.
>
> Is it a deficiency?

Obviously I have not thought about such deeply enough (and I do
not remember ever thinking about it that much). It merely feels
inelegant (to me).

On 5/30/2023 6:43 AM, Scott Lurndal wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>> On 5/29/23 9:38 AM, Scott Lurndal wrote:
>
>>> The current version (DDI0487_I_a) is up to 11,952 pages.
>>
>
>> (From my quick glance and a little I remember reading earlier,
>> AArch64 has a substantial variety of special instructions.
>> Providing some "complex/specialized" instructions, e.g.,
>> load/store pair, may be preferred over idiom recognition or the
>> somewhat sophisticated-seeming instruction modifiers of My 66000.
>> The cost of recognizing the idiom ll/add/sc versus that of
>> implementing atomic add (versus just letting such simple ll/sc
>> operations 'unnecessarily' fail sometimes) may not be difficult to
>> estimate in isolation, but one design choice will impact others.
>
> The initial AArch64 architecture had load exclusive/store exclusive
> (a la LL/SC). However, customers were already planning
> CPU implementations with large core counts (e.g. 48 for the Cavium
> ThunderX processor) and LL/SC is a poor choice[*] for large processor
> count system. Additonally, PCI express added support for atomic
> operations which require support from the processor complex so ARM
> added the Large System Extensions as the first ARMv8.1 feature
> wich added a full set of atomic operations to the ISA.
>
> [*] As a long time OS designer, I'd argue that LL/SC is a bad choice
> period; I still think the Burroughs LOK/UNLK and WAIT/CAUSE
> instructions were the best analog to software mutex and
> condition variable functionality that have been implemented in
> hardware to date.

Burroughs designers were generally language and compiler people, and the
ISAs were generally a direct implementation of HLL concepts. Other
company ISAs were/are designed by HW people and reflected gate concerns,
with "Will be fixed in the compiler" armwaving.

Mitch is the rare designer with feet in both.

In article <u58t0i$2lt0v$1@dont-email.me>, BGB <cr88192@gmail.com> wrote:
>On 5/31/2023 7:16 PM, Dan Cross wrote:
>> In article <u58001$2f7p9$1@dont-email.me>, BGB <cr88192@gmail.com> wrote:
>>> On 5/31/2023 7:04 AM, Dan Cross wrote:
>>>> We were in alt.os.development. The entire thing evolved out of
>>>> a discussion about x86S. Indeed, in hist first post on the
>>>> matter, BGB suggested his BJX2 as a replacement for x86:
>>>> https://groups.google.com/g/alt.os.development/c/doFB22kNPJE/m/gIeuGffeCAAJ
>>>>
>>>> In which he says,
>>>>
>>>> |Ironically, if one goes over to software managed TLB, then the whole
>>>> |"nested page table" thing can disappear into the noise (as it is all
>>>> |software).
>>>>
>>>> Which was the genesis of this entire thread of discussion: We
>>>> were explicitly talking about server-class CPUs. If he wants to
>>>> backtrack now and talk about embedded processors, whatever, but
>>>> that's certainly not how the discussion started.
>>>>
>>>
>>> I missed that point, it seems...
>>> And/or forgot, I am not sure which.
>>
>> The subject of the thread was "x86-S".
>
>Where did either the linked article or thread prior to this point say it
>was an exclusively server feature?...

We were talking about systems software design in the context of
x86S, and you claim you were talking about embedded designs. We
were talking about hypervisors and virtual machines, and you
claim you were talking about emulation.

>It was talking about simplifying x86 to be x86-64 only, but nothing
>really about servers or data-centers...

What application domains do you think that x86S targets? I
suppose there's still demand for desktops and laptops, but that
is hardly the embedded domain you claim you were talking about.

>As I saw it, more like, x86-S kinda eliminates some of the main "selling
>points" of "classic x86".
>
>The only time I remember any of this "server stuff" came up (much later
>in the thread), I said that it was outside the target domain of BJX2.

I think, bluntly, that you didn't understand the technical parts
of the conversation.

>It would have been pointless to have been "covertly" talking about
>servers only to be like, "yeah, no, that is not what I am doing here".

I think you thought you were talking about something that you
turned out not to know much about, and now you're trying to
backtrack to save face.

>But, then again, it is not exactly like modern PCs are really all that
>usable for retro-computing in the first place (with most of the PC
>retro-computing community mostly trading in 20+ year old parts).
>
>At this point, there isn't really much reason to keep using x86 apart
>from inertia. You could have pretty much everything jump over to ARM or
>similar and emulation, and if it were pulled off well, hardly anyone
>would notice...

And software compatibility, capacity, preserving existing design
investments, etc, etc, etc.

>It has been a sinking ship for a while, like the need to resort to
>emulators to run DOS or Win16 software on modern Windows (because MS
>didn't add emulation for these as a built-in feature in the move to
>64-bits).

This statement alone leads me to believe you are again talking
about things that you really don't know very much about.

>Nevermind if the retro-computing guys mostly dislike emulation, and
>instead want everything running on "original hardware" (well, except
>if/when modern PCs become retro). (Say, "Start hoarding now, this stuff
>will be gold in 25 or 30 years...", particularly the random/obscure "junk").
>
>OTOH, just saw a video recently where someone was talking about their
>difficulty getting ahold of an obscure variant of Game Boy knock-off
>that was sold mostly in Brazil (AKA: "Cougar Boy"). (Kind of a flop when
>it was new, rare and expensive now).

None of this is at all relevant.

>>> But, yeah, I guess maybe one can argue it doesn't make sense for server
>>> class CPUs, but there are uses for emulation/virtualization in embedded
>>> contexts as well (I had more thought of virtualization more like
>>> "emulation, but with hardware accelerated memory access").
>>
>> Emulation != Virtualization in this context
>> https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
>
>Possibly, but this is not the only way I have seen the term used...

We were talking about hypervisors. If you don't know what that
implies with respect to system design, that's fine, but perhaps
consider refraining from commenting as if you do.

>I was using it in a more narrow sense of "does not need to emulate
>memory access and address translation entirely in software".
>
>But, not necessarily in the sense of "does not require a JIT cache or
>translation stages" (nor in the sense that the hardware interfaces
>provided in the VM match those of the native machine).
>
>Well, at least short of having some way to have a fully programmable
>(software-defined) instruction decoder.

This is just nonsense.

Anyway, this is ridiculous at this point. I'm sorry, but you've
got some learning to do before your opinions should be taken at
all seriously.

- Dan C.

Ivan Godard <ivan@millcomputing.com> writes:
>On 5/30/2023 6:43 AM, Scott Lurndal wrote:
>> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>>> On 5/29/23 9:38 AM, Scott Lurndal wrote:
>>
>>>> The current version (DDI0487_I_a) is up to 11,952 pages.
>>>
>>
>>> (From my quick glance and a little I remember reading earlier,
>>> AArch64 has a substantial variety of special instructions.
>>> Providing some "complex/specialized" instructions, e.g.,
>>> load/store pair, may be preferred over idiom recognition or the
>>> somewhat sophisticated-seeming instruction modifiers of My 66000.
>>> The cost of recognizing the idiom ll/add/sc versus that of
>>> implementing atomic add (versus just letting such simple ll/sc
>>> operations 'unnecessarily' fail sometimes) may not be difficult to
>>> estimate in isolation, but one design choice will impact others.
>>
>> The initial AArch64 architecture had load exclusive/store exclusive
>> (a la LL/SC). However, customers were already planning
>> CPU implementations with large core counts (e.g. 48 for the Cavium
>> ThunderX processor) and LL/SC is a poor choice[*] for large processor
>> count system. Additonally, PCI express added support for atomic
>> operations which require support from the processor complex so ARM
>> added the Large System Extensions as the first ARMv8.1 feature
>> wich added a full set of atomic operations to the ISA.
>>
>> [*] As a long time OS designer, I'd argue that LL/SC is a bad choice
>> period; I still think the Burroughs LOK/UNLK and WAIT/CAUSE
>> instructions were the best analog to software mutex and
>> condition variable functionality that have been implemented in
>> hardware to date.
>
>Burroughs designers were generally language and compiler people,

As one of them myself, I'd instead say that they were _informed_
by language and compiler people; one must recall that these
architectures were designed in the first couple years of
the 1960's, informed by earlier designs from the 1950s (Electrodata Corporation).

> and the
>ISAs were generally a direct implementation of HLL concepts.

That is, indeed, true. To the extent that on medium systems
most COBOL statements generated a single machine instruction.

>Other
>company ISAs were/are designed by HW people and reflected gate concerns,

We were always concerned about the hardware cost and implementation.

>with "Will be fixed in the compiler" armwaving.

HUH?

scott@slp53.sl.home (Scott Lurndal) writes:
>I've seen much worse than the ARM documentation (e.g. RISC-V).

Interestingly, I found the RISC-V documentation great for the things I
have needed up to now, while I found the ARM A64 documentation
unwieldy.

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

On 6/1/2023 6:38 AM, Dan Cross wrote:

<snip>

>
> I think you thought you were talking about something that you
> turned out not to know much about, and now you're trying to
> backtrack to save face.
>

<snip>

>
> This is just nonsense.
>
> Anyway, this is ridiculous at this point. I'm sorry, but you've
> got some learning to do before your opinions should be taken at
> all seriously.
>

What I think, is that you are projecting your thoughts onto others and
have been acting like a condescending jerk this whole time.

All I have to say at this point is, screw it, I have had enough of this...

The reason a lot of the stuff I say has nothing to do with server use
cases, is because (from my perspective) it was never about servers in
the first place.

Like, FFS, why would I bother to mention projects like the "Commander
X16" and similar in relation to a server context?... Even I am not that
*that* stupid... ( You aren't going to run a server on a 6502 or
similar, but, you *may* have reason to want to emulate one for
retrogaming, like, FFS).

Like, maybe allow that if, what someone is saying has nothing to do with
whatever "implied" context, that in-fact, this is not the context they
were talking about.

....

But, I am done with this, and am not inclined to respond further.

Scott Lurndal wrote:
>
> There were two classes of interrupt priority - normal and real-time. Each
> was handled by a different IR, where the real-time IR had a higher scheduling
> priority than any other IR or user task. Real-time were basically used for
> older document processors (check reader/sorters) to handle the pocket select
> function - after reading the MICR at the read station, the host would select
> which pocket to sort the document into in the very short interval between
> the read head and the pocket select gates when processing documents at
> 2500 documents per minute (on up to 10 sorters simultaneously). If the
> host didn't respond in time, the document would be rejected and need to
> be re-sorted, so the real-time interrupts were key to keeping the sorters
> running 24x7 or during the overnight batch period.

BT,DT, sort of:

My very first professional PC programming task was the write code for a
huge (4+ meter long) OCR card/reader/document sorter. (Spring/summer 1982)

Since this was the original 4.77 Mhz 8088 PC, the serial port had zero
buffering, so my interrupt driver for that port needed to never take
more than the 1ms gap between characters to read and empty the input
port, then the main program (which was mostly polling the input buffer
status flag) had to gather the full record and figure out the
destination gate. This also had to happen within the time it took the
card to travel about 20 cm. I don't remember how many milliseconds I had
available here since I never had any issue staying within the limit.

These original cards did not have any check digits, so a misread which
changed the leading digit would totally modify the value of the card,
worst case from 40 to 1000 NOK. I added two check digits ASAP but still
had to handle the old ones for the next 3+ years until they were all
invalidated.

Terje

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Scott Lurndal wrote:
>>
>> There were two classes of interrupt priority - normal and real-time. Each
>> was handled by a different IR, where the real-time IR had a higher scheduling
>> priority than any other IR or user task. Real-time were basically used for
>> older document processors (check reader/sorters) to handle the pocket select
>> function - after reading the MICR at the read station, the host would select
>> which pocket to sort the document into in the very short interval between
>> the read head and the pocket select gates when processing documents at
>> 2500 documents per minute (on up to 10 sorters simultaneously). If the
>> host didn't respond in time, the document would be rejected and need to
>> be re-sorted, so the real-time interrupts were key to keeping the sorters
>> running 24x7 or during the overnight batch period.
>
>BT,DT, sort of:
>
>My very first professional PC programming task was the write code for a
>huge (4+ meter long) OCR card/reader/document sorter. (Spring/summer 1982)
>
>Since this was the original 4.77 Mhz 8088 PC, the serial port had zero
>buffering, so my interrupt driver for that port needed to never take
>more than the 1ms gap between characters to read and empty the input
>port, then the main program (which was mostly polling the input buffer
>status flag) had to gather the full record and figure out the
>destination gate. This also had to happen within the time it took the
>card to travel about 20 cm. I don't remember how many milliseconds I had
>available here since I never had any issue staying within the limit.

Sounds about the same, except on the Burroughs systems
the pocket select code was written in COBOL and was running
as a standard user task under the MCP. In early versions of the MCP,
it called the pocket select code directly at interrupt in the privileged
context of the MCP (trusting the application coder not to
do something bad). Later MCP's associated a real-time IR
with the task to run the pocket select routine.

>
>These original cards did not have any check digits, so a misread which
>changed the leading digit would totally modify the value of the card,
>worst case from 40 to 1000 NOK. I added two check digits ASAP but still
>had to handle the old ones for the next 3+ years until they were all
>invalidated.

Ouch.

MitchAlsup wrote:
> On Wednesday, May 31, 2023 at 6:02:24 PM UTC-5, Scott Lurndal wrote:
>> MitchAlsup <Mitch...@aol.com> writes:
>>> On Wednesday, May 31, 2023 at 2:57:48=E2=80=AFPM UTC-5, Scott Lurndal wrote=
>>> :
>>
>>>> One of the acid tests at a national lab that will go unnamed is for=20
>>>> all cores to pound on a single cache line (using a spin lock). Starvation=
>>> =20
>>>> was a 'fail'.=20
>>> <
>>> Are the contenders of the same priority ?? Are they of the same Privilege ?=
>>
>> Yes. Although I'm not aware of either priority or privilege
>> being factored into Intel or AMD's coherency protocols.
> <
> Yes, priority and privilege are not considered in AMD or Intel (and I suspect
> ARM). However, I was looking at a "bus interconnect" that is cache-line wide
> (1-beat is 512-bits) and thinking that a 8-bit command, 64-bit address and
> a handful of other bits, there are a lot of bits left over, so it would create
> no real disturbance on the "bus" is priority (6-bits) and/or privilege (2-bits)
> tag long with the request.
> <
> And as I explained above, there is an ATOMIC event, and SW today mainly
> uses the event to guard a critical section. It is only when you get into
> CAS, DCAS,... where you are trying to perform "some" of the critical
> section in the ATOMIC event (or not having a critical section at all).
>
I'll repeat here that XADD is my personal favorite: I can implement
queues and buffers with a few of these: Typically a single XADD
determines which buffer slot you can access, and that slot is yours.
Make each slot (at least) a cache line wide and you get rid of secondary
interference.

Even if a bunch of threads are hammering the same counter, they will
each get a unique value (slot index) back, it just might take a little
time. Forward progress is guaranteed.

Terje

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>MitchAlsup wrote:
>> On Wednesday, May 31, 2023 at 6:02:24 PM UTC-5, Scott Lurndal wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>> On Wednesday, May 31, 2023 at 2:57:48=E2=80=AFPM UTC-5, Scott Lurndal wrote=
>>>> :
>>>
>>>>> One of the acid tests at a national lab that will go unnamed is for=20
>>>>> all cores to pound on a single cache line (using a spin lock). Starvation=
>>>> =20
>>>>> was a 'fail'.=20
>>>> <
>>>> Are the contenders of the same priority ?? Are they of the same Privilege ?=
>>>
>>> Yes. Although I'm not aware of either priority or privilege
>>> being factored into Intel or AMD's coherency protocols.
>> <
>> Yes, priority and privilege are not considered in AMD or Intel (and I suspect
>> ARM). However, I was looking at a "bus interconnect" that is cache-line wide
>> (1-beat is 512-bits) and thinking that a 8-bit command, 64-bit address and
>> a handful of other bits, there are a lot of bits left over, so it would create
>> no real disturbance on the "bus" is priority (6-bits) and/or privilege (2-bits)
>> tag long with the request.
>> <
>> And as I explained above, there is an ATOMIC event, and SW today mainly
>> uses the event to guard a critical section. It is only when you get into
>> CAS, DCAS,... where you are trying to perform "some" of the critical
>> section in the ATOMIC event (or not having a critical section at all).
>>
>I'll repeat here that XADD is my personal favorite: I can implement
>queues and buffers with a few of these: Typically a single XADD
>determines which buffer slot you can access, and that slot is yours.
>Make each slot (at least) a cache line wide and you get rid of secondary
>interference.
>

ARM64 has a full set of atomic math ops (add, xor, bit set, bit clear,
signed min and signed max).

>Even if a bunch of threads are hammering the same counter, they will
>each get a unique value (slot index) back, it just might take a little
>time. Forward progress is guaranteed.

So long as the coherency protocol guarantees some level of fairness;
one still requires exclusive access to the cache line for XADD or any
atomic operation. If other cores are continuously contenting for
the same line starvation can occur if the protocol doesn't guarantee
forward progress.

XADD to physical addresses with device (uncacheable) memory semantics
are up to the receiving endpoint which needs to guarantee forward
progress (likely by buffering incoming requests with a fifo and credits).

Scott Lurndal wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> MitchAlsup wrote:
>>> On Wednesday, May 31, 2023 at 6:02:24 PM UTC-5, Scott Lurndal wrote:
>>>> MitchAlsup <Mitch...@aol.com> writes:
>>>>> On Wednesday, May 31, 2023 at 2:57:48=E2=80=AFPM UTC-5, Scott Lurndal wrote=
>>>>> :
>>>>
>>>>>> One of the acid tests at a national lab that will go unnamed is for=20
>>>>>> all cores to pound on a single cache line (using a spin lock). Starvation=
>>>>> =20
>>>>>> was a 'fail'.=20
>>>>> <
>>>>> Are the contenders of the same priority ?? Are they of the same Privilege ?=
>>>>
>>>> Yes. Although I'm not aware of either priority or privilege
>>>> being factored into Intel or AMD's coherency protocols.
>>> <
>>> Yes, priority and privilege are not considered in AMD or Intel (and I suspect
>>> ARM). However, I was looking at a "bus interconnect" that is cache-line wide
>>> (1-beat is 512-bits) and thinking that a 8-bit command, 64-bit address and
>>> a handful of other bits, there are a lot of bits left over, so it would create
>>> no real disturbance on the "bus" is priority (6-bits) and/or privilege (2-bits)
>>> tag long with the request.
>>> <
>>> And as I explained above, there is an ATOMIC event, and SW today mainly
>>> uses the event to guard a critical section. It is only when you get into
>>> CAS, DCAS,... where you are trying to perform "some" of the critical
>>> section in the ATOMIC event (or not having a critical section at all).
>>>
>> I'll repeat here that XADD is my personal favorite: I can implement
>> queues and buffers with a few of these: Typically a single XADD
>> determines which buffer slot you can access, and that slot is yours.
>> Make each slot (at least) a cache line wide and you get rid of secondary
>> interference.
>>
>
> ARM64 has a full set of atomic math ops (add, xor, bit set, bit clear,
> signed min and signed max).
>
>> Even if a bunch of threads are hammering the same counter, they will
>> each get a unique value (slot index) back, it just might take a little
>> time. Forward progress is guaranteed.
>
> So long as the coherency protocol guarantees some level of fairness;
> one still requires exclusive access to the cache line for XADD or any
> atomic operation. If other cores are continuously contenting for
> the same line starvation can occur if the protocol doesn't guarantee
> forward progress.

This is definitely correct, and the main reason why sensible bus
protocol designers will grant any core which asks for and gets exclusive
access to a cache line, full ownership for at least the time taken by a
single read/modify/store transaction. I.e. basically two back-to-back
bus operations.

If you can't guarantee this, then you are indeed very likely to run into
starvation scenarios (and fail that unnamed national lab hammer test).
>
> XADD to physical addresses with device (uncacheable) memory semantics
> are up to the receiving endpoint which needs to guarantee forward
> progress (likely by buffering incoming requests with a fifo and credits).
>
This would be nice to have, but I would personally be happy with a sw
interface where the XADD tells me which slot in the device memory map to
access.

Terje

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

On Friday, June 2, 2023 at 2:58:45 PM UTC-5, Terje Mathisen wrote:
> Scott Lurndal wrote:
> > Terje Mathisen <terje.m...@tmsw.no> writes:
> >> MitchAlsup wrote:
> >>> On Wednesday, May 31, 2023 at 6:02:24 PM UTC-5, Scott Lurndal wrote:
> >>>> MitchAlsup <Mitch...@aol.com> writes:
> >>>>> On Wednesday, May 31, 2023 at 2:57:48=E2=80=AFPM UTC-5, Scott Lurndal wrote=
> >>>>> :
> >>>>
> >>>>>> One of the acid tests at a national lab that will go unnamed is for=20
> >>>>>> all cores to pound on a single cache line (using a spin lock). Starvation=
> >>>>> =20
> >>>>>> was a 'fail'.=20
> >>>>> <
> >>>>> Are the contenders of the same priority ?? Are they of the same Privilege ?=
> >>>>
> >>>> Yes. Although I'm not aware of either priority or privilege
> >>>> being factored into Intel or AMD's coherency protocols.
> >>> <
> >>> Yes, priority and privilege are not considered in AMD or Intel (and I suspect
> >>> ARM). However, I was looking at a "bus interconnect" that is cache-line wide
> >>> (1-beat is 512-bits) and thinking that a 8-bit command, 64-bit address and
> >>> a handful of other bits, there are a lot of bits left over, so it would create
> >>> no real disturbance on the "bus" is priority (6-bits) and/or privilege (2-bits)
> >>> tag long with the request.
> >>> <
> >>> And as I explained above, there is an ATOMIC event, and SW today mainly
> >>> uses the event to guard a critical section. It is only when you get into
> >>> CAS, DCAS,... where you are trying to perform "some" of the critical
> >>> section in the ATOMIC event (or not having a critical section at all)..
> >>>
> >> I'll repeat here that XADD is my personal favorite: I can implement
> >> queues and buffers with a few of these: Typically a single XADD
> >> determines which buffer slot you can access, and that slot is yours.
> >> Make each slot (at least) a cache line wide and you get rid of secondary
> >> interference.
> >>
> >
> > ARM64 has a full set of atomic math ops (add, xor, bit set, bit clear,
> > signed min and signed max).
> >
> >> Even if a bunch of threads are hammering the same counter, they will
> >> each get a unique value (slot index) back, it just might take a little
> >> time. Forward progress is guaranteed.
> >
> > So long as the coherency protocol guarantees some level of fairness;
> > one still requires exclusive access to the cache line for XADD or any
> > atomic operation. If other cores are continuously contenting for
> > the same line starvation can occur if the protocol doesn't guarantee
> > forward progress.
<
> This is definitely correct, and the main reason why sensible bus
> protocol designers will grant any core which asks for and gets exclusive
> access to a cache line, full ownership for at least the time taken by a
> single read/modify/store transaction. I.e. basically two back-to-back
> bus operations.
<
Most busses and most cache coherence protocols fail to provide any
guarantee that 2 cache lines are ever co-resident over more than 1 cycle.
This was the stumbling block I ran into at AMD when Fred Weber ask me
"Why can't we just give MS DCAC ?". The pursuit of which lead to ASF
and later ESM.
>
> If you can't guarantee this, then you are indeed very likely to run into
> starvation scenarios (and fail that unnamed national lab hammer test).
<
Try guaranteeing 8 cache lines are co-resident over <say> 8 cycles !!
<
> >
> > XADD to physical addresses with device (uncacheable) memory semantics
> > are up to the receiving endpoint which needs to guarantee forward
> > progress (likely by buffering incoming requests with a fifo and credits).
> >
> This would be nice to have, but I would personally be happy with a sw
> interface where the XADD tells me which slot in the device memory map to
> access.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup <MitchAlsup@aol.com> writes:
>On Friday, June 2, 2023 at 2:58:45=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>> Scott Lurndal wrote:=20
>> > Terje Mathisen <terje.m...@tmsw.no> writes:=20
>> >> MitchAlsup wrote:=20

>> > So long as the coherency protocol guarantees some level of fairness;=20
>> > one still requires exclusive access to the cache line for XADD or any=
>=20
>> > atomic operation. If other cores are continuously contenting for=20
>> > the same line starvation can occur if the protocol doesn't guarantee=20
>> > forward progress.
><
>> This is definitely correct, and the main reason why sensible bus=20
>> protocol designers will grant any core which asks for and gets exclusive=
>=20
>> access to a cache line, full ownership for at least the time taken by a=
>=20
>> single read/modify/store transaction. I.e. basically two back-to-back=20
>> bus operations.=20
><
>Most busses and most cache coherence protocols fail to provide any
>guarantee that 2 cache lines are ever co-resident over more than 1 cycle.
>This was the stumbling block I ran into at AMD when Fred Weber ask me
>"Why can't we just give MS DCAC ?". The pursuit of which lead to ASF
>and later ESM.

Ah yes, I know Fred - he was one of our tech advisory board members.

ASF, TSX, even ARM hasn't been able to effectively do transactional
memory yet.

On Friday, June 2, 2023 at 4:31:23 PM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Friday, June 2, 2023 at 2:58:45=E2=80=AFPM UTC-5, Terje Mathisen wrote:
> >> Scott Lurndal wrote:=20
> >> > Terje Mathisen <terje.m...@tmsw.no> writes:=20
> >> >> MitchAlsup wrote:=20
>
> >> > So long as the coherency protocol guarantees some level of fairness;=20
> >> > one still requires exclusive access to the cache line for XADD or any=
> >=20
> >> > atomic operation. If other cores are continuously contenting for=20
> >> > the same line starvation can occur if the protocol doesn't guarantee=20
> >> > forward progress.
> ><
> >> This is definitely correct, and the main reason why sensible bus=20
> >> protocol designers will grant any core which asks for and gets exclusive=
> >=20
> >> access to a cache line, full ownership for at least the time taken by a=
> >=20
> >> single read/modify/store transaction. I.e. basically two back-to-back=20
> >> bus operations.=20
> ><
> >Most busses and most cache coherence protocols fail to provide any
> >guarantee that 2 cache lines are ever co-resident over more than 1 cycle..
> >This was the stumbling block I ran into at AMD when Fred Weber ask me
> >"Why can't we just give MS DCAS ?". The pursuit of which lead to ASF
> >and later ESM.
<
> Ah yes, I know Fred - he was one of our tech advisory board members.
>
> ASF, TSX, even ARM hasn't been able to effectively do transactional
> memory yet.
<
I never intended my ATOMICs to be TM, I always intended them to be ATOMICs.
They can be used to support TM, but they are not TM.
<
What ESM can do is to reduce the number of ATOMIC events, which in an of
itself reduces contention in the system.
<
Oh, and BTW, I don't think anyone will ever get TM working "all that well".
The basic problem is that SW wants a recursive definition of transaction.

On 5/29/23 3:27 PM, Dan Cross wrote:
> In article <2023May28.165701@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <u4rm3o$52b5$1@dont-email.me>, BGB <cr88192@gmail.com> wrote:
>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>
>>> I haven't a clue. However, most undergrads who take an
>>> architecture course do about the same.
>>
>> Implement a new architecture in an FPGA and get it to run Doom (which
>> also means retargeting a compiler for his architecture)? I very much
>> doubt it.

I am impressed by his accomplishments. I wish the world would
better exploit such human resources. He obviously has
psychological issues (autism has been mentioned) which would make
extracting the value more difficult, but he seems intelligent and
*able to accomplish things*.

> Actually, I really don't think that is that far off. Maybe they
> won't port a compiler or a reasonably large game, but so what?
> By the time anyone is doing that, most of the really hard work
> has been done.

Porting a compiler like GCC or LLVM from a similar supported ISA
may not be extraordinarily difficult (but I suspect such still
involves a substantial investment in time). Undergraduates often
have more resources and clearer guidelines than a relatively
isolated self-taught person.

In article <u5ifdv$s3i$1@dont-email.me>,
Paul A. Clayton <paaronclayton@gmail.com> wrote:
>On 5/29/23 3:27 PM, Dan Cross wrote:
>> In article <2023May28.165701@mips.complang.tuwien.ac.at>,
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>> In article <u4rm3o$52b5$1@dont-email.me>, BGB <cr88192@gmail.com> wrote:
>>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>>
>>>> I haven't a clue. However, most undergrads who take an
>>>> architecture course do about the same.
>>>
>>> Implement a new architecture in an FPGA and get it to run Doom (which
>>> also means retargeting a compiler for his architecture)? I very much
>>> doubt it.
>
>I am impressed by his accomplishments. I wish the world would
>better exploit such human resources. He obviously has
>psychological issues (autism has been mentioned) which would make
>extracting the value more difficult, but he seems intelligent and
>*able to accomplish things*.

It may be insensitive, but I don't really care what his problem
is, and I plonked him.

>> Actually, I really don't think that is that far off. Maybe they
>> won't port a compiler or a reasonably large game, but so what?
>> By the time anyone is doing that, most of the really hard work
>> has been done.
>
>Porting a compiler like GCC or LLVM from a similar supported ISA
>may not be extraordinarily difficult (but I suspect such still
>involves a substantial investment in time). Undergraduates often
>have more resources and clearer guidelines than a relatively
>isolated self-taught person.

Certainly. But just because someone is clever and does a thing
that does not a) imply that that person is qualified to work at
a higher level, or b) that they are an expert at the thing.

One recognizes an undergraduate education as the beginning of
one's educational journey (be it followed by further study in an
academic context or a professional context), not the end.

- Dan C.

On 6/5/2023 4:12 AM, Dan Cross wrote:
> In article <u5ifdv$s3i$1@dont-email.me>,
> Paul A. Clayton <paaronclayton@gmail.com> wrote:
>> On 5/29/23 3:27 PM, Dan Cross wrote:
>>> In article <2023May28.165701@mips.complang.tuwien.ac.at>,
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>> In article <u4rm3o$52b5$1@dont-email.me>, BGB <cr88192@gmail.com> wrote:
>>>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>>>
>>>>> I haven't a clue. However, most undergrads who take an
>>>>> architecture course do about the same.
>>>>
>>>> Implement a new architecture in an FPGA and get it to run Doom (which
>>>> also means retargeting a compiler for his architecture)? I very much
>>>> doubt it.
>>
>> I am impressed by his accomplishments. I wish the world would
>> better exploit such human resources. He obviously has
>> psychological issues (autism has been mentioned) which would make
>> extracting the value more difficult, but he seems intelligent and
>> *able to accomplish things*.
>
> It may be insensitive, but I don't really care what his problem
> is, and I plonked him.
>
>>> Actually, I really don't think that is that far off. Maybe they
>>> won't port a compiler or a reasonably large game, but so what?
>>> By the time anyone is doing that, most of the really hard work
>>> has been done.
>>
>> Porting a compiler like GCC or LLVM from a similar supported ISA
>> may not be extraordinarily difficult (but I suspect such still
>> involves a substantial investment in time). Undergraduates often
>> have more resources and clearer guidelines than a relatively
>> isolated self-taught person.
>
> Certainly. But just because someone is clever and does a thing
> that does not a) imply that that person is qualified to work at
> a higher level, or b) that they are an expert at the thing.
>
> One recognizes an undergraduate education as the beginning of
> one's educational journey (be it followed by further study in an
> academic context or a professional context), not the end.

An undergraduate education was beyond the end for me. Despite having
taught at the undergrad and graduate levels, my only diploma shows that
I'm a proud graduate of Deer Isle High School. Graduated third in my
class, mind you - of ten.

Over the years I've hired a fair number of technical people. I've always
had the policy to impose no recruiting requirement that I myself could
not satisfy. However, there are some jobs I would actively seek out PhDs
for, because sometimes you want someone with a demonstrated capacity to
slog through interminable crap.

In article <u5kh8c$ap5s$1@dont-email.me>,
Ivan Godard <ivan@millcomputing.com> wrote:
>On 6/5/2023 4:12 AM, Dan Cross wrote:
>[snip]
>> One recognizes an undergraduate education as the beginning of
>> one's educational journey (be it followed by further study in an
>> academic context or a professional context), not the end.
>
>An undergraduate education was beyond the end for me. Despite having
>taught at the undergrad and graduate levels, my only diploma shows that
>I'm a proud graduate of Deer Isle High School. Graduated third in my
>class, mind you - of ten.
>
>Over the years I've hired a fair number of technical people. I've always
>had the policy to impose no recruiting requirement that I myself could
>not satisfy. However, there are some jobs I would actively seek out PhDs
>for, because sometimes you want someone with a demonstrated capacity to
>slog through interminable crap.

I believe that this is missing the overall point: perhaps you
did not attend a university, but did you stop learning after you
graduated from Deer Isle high school? Certainly not.

When I was in the US Marine Corps, I met many incredibly
brilliant people who had never walked the halls of any academy.
It is not the sheepskin that matters, it's the learning process.
My point specifically in this thread is that mastery of the
basics does not make one an expert. Specifically, achieving
something on par with what someone who goes through the basics
achieves is very well and good, but it is still a beginning, not
an end.

- Dan C.

On 5/29/23 9:07 PM, MitchAlsup wrote:
> On Monday, May 29, 2023 at 7:07:58 PM UTC-5, Paul A. Clayton wrote:
[snip]
>> While *some* of that is bloat from the print/PDF format which
>> encourages replication of information and page breaks (e.g., a
>> brief look noted that instruction descriptions start at the top of
>> a page) and some comes from how the information is organized, a
>> *lot* seems to be from "essential complexity".
>
> I am of the opinion that each instruction should be on its own page
> (or set of pages). I am further of the opinion that if you need more
> than 2 pages to describe the instruction, you should provide a
> summary on one page and a forward pointer to where you discuss
> the topic fully and in scope with all the other instructions involved.

I am of the opinion that most documentation should not use a
single-view print-oriented format (like PDF). (I do admit that
spatial recognition is important for re-referencing content,
especially when one cannot think of the appropriate search terms
but has a memory of "landmarks" and general location. I suspect
there are ways to provide similar memory keys without requiring
consistent pagination.)

While humans can filter consistent unimportant details when, e.g.,
each instruction description has the same basic format, I suspect
that supporting multiple views of the information might be more
useful.

When viewing documentation on a monitor, one might prefer the
ability to optionally inline common material rather than use a
link. (A PDF viewer can provide a preview of the link target, but
this preview will be sized according to a general concept of
utility and not consider the content of the linked material.)

Maybe I am strange and/or mistrained in losing focus from link
following. (I can see how making content visible or hidden
dynamically could further hurt the "spatial memory", but for
shortish content such might be better than a link.)

(I do not know what the electronic display version would be for
having two or more books open on a desk along with various sheets
of notes. Tabbed browsing provides some of this functionality
[though I suspect head turning to change context has some
psychological impact, especially if the side content has a less
comfortable viewing position which naturally draws one back to the
comfortable view of the main content], but the order/arrangement
of tabs is unlikely to mesh with one's mental model. I suspect
this is related to some people's preference for multiple screens;
a computer could easily change the display [virtual desktops have
been around for quite a while] but the navigation seems to be less
"natural" and more intentional [peripheral vision could also be a
factor].)

> Luckily for me, I only have 61 instructions....the rest of the ISA
> manual discusses Who, What, Where, When, and WHY.

Well, that also depends on how one counts instructions. E.g., ADD
is documented as one My 66000 instruction but could easily be
counted as 33 instructions, the 16-bit immediate form (which seems
to always be unsigned, i.e., not overflow) and 32 forms using two
input encoding with I, S1, S2, S, and d bits specifying which of
the 32 forms is used. (I am not criticizing. I think this avoids
unnecessary complexity compared to

> I am of the opinion that certain groups of instructions are deserving
> of an entire chapter by themselves in a different book--such as multi-
> precision arithmetic, ATOMIC events, the ABI--ENTER and EXIT, ...
> <
> I am of the opinion that certain corners of an architecture are deserving
> of an entire book (say 200± pages)--such as: systems organization,
> interconnects, protocols, BOOT, messaging, interrupts, traps, exceptions
> and any special sequencing.

In a non-print medium, the concept of "book" may be less well
defined. While ebook software seems (like PDF viewers) to handle
large documents poorly, I do not think this is essential to the
fuzzing/coherence of the concept of "volume"/"book".
Distribution/packaging unit may be a reasonable definition for
"book", but size if often much less of a consideration than for
physical books.

> I currently have a book for each :: ISA, unprivileged Software Programming
> model, Systems architecture and programming model, 1-wide in-order
> µArchitecture, and ½ of a 6-wide GBOoO µArchitecture. All of this is under
> 1,000 pages total.
> <
> I also believe that one writes a document to 80% completion level,
> then starts moving stuff around until it flows better, then finishes
> the last 20%. The part of moving stuff around takes 25% of the total
> time.

And presumably moving stuff around also influences the content
itself. Gaining an understanding of how content relates to other
content presumably leads one to better management of completeness,
clarity, and conciseness.

[snip]
>> Organizing documentation seems challenging and undervalued.
>
> I took a class in technical writing at CMU 1974. It took until about
> 2000 for me to fully realize just how to write a document so that
> industrious well meaning engineers could not misinterpret what
> I wrote, and a few more years until I could write documents such
> that malevolent engineers could not misunderstand. {And then
> there was the semi-malevolent engineer who wanted to complain
> that I used the word '2-s complement integer arithmetic' too often.}

If one adds teaching non-experts, the challenge for documentation
seems even greater. Also clarity and concision (and "fun") are
probably more important when the reader can choose to ignore the
documentation, i.e., there can be a marketing aspect for some
documentation.

>> Increasing complexity along with a documentation legacy (both
>> expectations of established users and effort required to
>> reorganize content for clarity and concision) increase the cost of
>> producing good documentation. Yet I think print-oriented and
>> complete-in-one-volume-for-all-users presentation unnecessarily
>> increases the difficulty.

On Saturday, June 10, 2023 at 2:57:37 PM UTC-5, Paul A. Clayton wrote:
> On 5/29/23 9:07 PM, MitchAlsup wrote:
> > On Monday, May 29, 2023 at 7:07:58 PM UTC-5, Paul A. Clayton wrote:
> [snip]
> >> While *some* of that is bloat from the print/PDF format which
> >> encourages replication of information and page breaks (e.g., a
> >> brief look noted that instruction descriptions start at the top of
> >> a page) and some comes from how the information is organized, a
> >> *lot* seems to be from "essential complexity".
> >
> > I am of the opinion that each instruction should be on its own page
> > (or set of pages). I am further of the opinion that if you need more
> > than 2 pages to describe the instruction, you should provide a
> > summary on one page and a forward pointer to where you discuss
> > the topic fully and in scope with all the other instructions involved.
>
> I am of the opinion that most documentation should not use a
> single-view print-oriented format (like PDF). (I do admit that
> spatial recognition is important for re-referencing content,
> especially when one cannot think of the appropriate search terms
> but has a memory of "landmarks" and general location. I suspect
> there are ways to provide similar memory keys without requiring
> consistent pagination.)
<
Is rampant cross reference links not sufficient here ?
>
> While humans can filter consistent unimportant details when, e.g.,
> each instruction description has the same basic format, I suspect
> that supporting multiple views of the information might be more
> useful.
>
> When viewing documentation on a monitor, one might prefer the
> ability to optionally inline common material rather than use a
> link. (A PDF viewer can provide a preview of the link target, but
> this preview will be sized according to a general concept of
> utility and not consider the content of the linked material.)
<
I was thinking more about haw a Supervisor Call and a Supervisor
return need a quick definition in ISA and then the pair of them plus
interrupts and exceptions all together require a complete chapter
to annotate how they work together in the "system" and how they
interact over a period of time spanning multiple instructions
where there is potential for exception and interrupts to transpire
"all at the same time". Where chapter is on the order of 20 pages.
>
> Maybe I am strange and/or mistrained in losing focus from link
> following. (I can see how making content visible or hidden
> dynamically could further hurt the "spatial memory", but for
> shortish content such might be better than a link.)
<
You need a reader where you can follow a link and return whence
you followed.
<
But (the BIG but) all sufficiently well described architectures end
up in the position that the reader has to read all the documents in
order to be in a position to read the documents with understanding.
<
At a place of employment, one needs a ceiling height by 40 foot
long "white board" to draw a schematic for the µArchitecture in
sufficient detail to find and reason about (then correct) the
"schematic". Scrolling around on a screen with a schematic that
is 100×screen sizes big is not workable....
>
> (I do not know what the electronic display version would be for
> having two or more books open on a desk along with various sheets
> of notes. Tabbed browsing provides some of this functionality
> [though I suspect head turning to change context has some
> psychological impact, especially if the side content has a less
> comfortable viewing position which naturally draws one back to the
> comfortable view of the main content], but the order/arrangement
> of tabs is unlikely to mesh with one's mental model. I suspect
> this is related to some people's preference for multiple screens;
> a computer could easily change the display [virtual desktops have
> been around for quite a while] but the navigation seems to be less
> "natural" and more intentional [peripheral vision could also be a
> factor].)
>
> > Luckily for me, I only have 61 instructions....the rest of the ISA
> > manual discusses Who, What, Where, When, and WHY.
>
> Well, that also depends on how one counts instructions. E.g., ADD
> is documented as one My 66000 instruction but could easily be
> counted as 33 instructions, the 16-bit immediate form (which seems
> to always be unsigned, i.e., not overflow) and 32 forms using two
> input encoding with I, S1, S2, S, and d bits specifying which of
> the 32 forms is used. (I am not criticizing. I think this avoids
> unnecessary complexity compared to
<
There are 61 spellings the assembly language programmer has
to memorize to capture the whole instruction set in his head.
{Not to mention there is no SUB instruction, or NEG, or COMP
instruction, no FMULSUB, and a host of other "spellings".} in
My 66000 the OpCode describes the calculation, those other 32
forms describe the routing of operand to the calculation.
>
> > I am of the opinion that certain groups of instructions are deserving
> > of an entire chapter by themselves in a different book--such as multi-
> > precision arithmetic, ATOMIC events, the ABI--ENTER and EXIT, ...
> > <
> > I am of the opinion that certain corners of an architecture are deserving
> > of an entire book (say 200± pages)--such as: systems organization,
> > interconnects, protocols, BOOT, messaging, interrupts, traps, exceptions
> > and any special sequencing.
>
> In a non-print medium, the concept of "book" may be less well
> defined. While ebook software seems (like PDF viewers) to handle
> large documents poorly, I do not think this is essential to the
> fuzzing/coherence of the concept of "volume"/"book".
> Distribution/packaging unit may be a reasonable definition for
> "book", but size if often much less of a consideration than for
> physical books.
<
I (do) understand what you are getting at, but (as yet) we don't
really have a way of having 89 views into a document on 89 windows
so we can see all the nuances that one complicated instruction
brings to the party (for better or worse). {{See 10 minutes before
the end of Lawnmower Man}}
>
> > I currently have a book for each :: ISA, unprivileged Software Programming
> > model, Systems architecture and programming model, 1-wide in-order
> > µArchitecture, and ½ of a 6-wide GBOoO µArchitecture. All of this is under
> > 1,000 pages total.
> > <
> > I also believe that one writes a document to 80% completion level,
> > then starts moving stuff around until it flows better, then finishes
> > the last 20%. The part of moving stuff around takes 25% of the total
> > time.
>
> And presumably moving stuff around also influences the content
> itself.
<
absolutely--and you would not have been able to "see" it without
said movement.
<
> Gaining an understanding of how content relates to other
> content presumably leads one to better management of completeness,
> clarity, and conciseness.
<
And use the same word with the same meaning everywhere across
4-10 documents.
>
> [snip]
> >> Organizing documentation seems challenging and undervalued.
> >
> > I took a class in technical writing at CMU 1974. It took until about
> > 2000 for me to fully realize just how to write a document so that
> > industrious well meaning engineers could not misinterpret what
> > I wrote, and a few more years until I could write documents such
> > that malevolent engineers could not misunderstand. {And then
> > there was the semi-malevolent engineer who wanted to complain
> > that I used the word '2-s complement integer arithmetic' too often.}
>
> If one adds teaching non-experts, the challenge for documentation
> seems even greater. Also clarity and concision (and "fun") are
> probably more important when the reader can choose to ignore the
> documentation, i.e., there can be a marketing aspect for some
> documentation.
<
Yeah, you just tripled the difficulty.....
>
> >> Increasing complexity along with a documentation legacy (both
> >> expectations of established users and effort required to
> >> reorganize content for clarity and concision) increase the cost of
> >> producing good documentation. Yet I think print-oriented and
> >> complete-in-one-volume-for-all-users presentation unnecessarily
> >> increases the difficulty.

On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
> On 6/5/2023 4:12 AM, Dan Cross wrote:
> > In article <u5ifdv$s3i$1...@dont-email.me>,
> > Paul A. Clayton <paaron...@gmail.com> wrote:
> >> On 5/29/23 3:27 PM, Dan Cross wrote:
> >>> In article <2023May2...@mips.complang.tuwien.ac.at>,
> >>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
> >>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
> >>>>>> How many people have done much better with their hobby CPU ISA projects?...
> >>>>>
> >>>>> I haven't a clue. However, most undergrads who take an
> >>>>> architecture course do about the same.
> >>>>
> >>>> Implement a new architecture in an FPGA and get it to run Doom (which
> >>>> also means retargeting a compiler for his architecture)? I very much
> >>>> doubt it.
> >>
> >> I am impressed by his accomplishments. I wish the world would
> >> better exploit such human resources. He obviously has
> >> psychological issues (autism has been mentioned) which would make
> >> extracting the value more difficult, but he seems intelligent and
> >> *able to accomplish things*.
> >
> > It may be insensitive, but I don't really care what his problem
> > is, and I plonked him.
> >
> >>> Actually, I really don't think that is that far off. Maybe they
> >>> won't port a compiler or a reasonably large game, but so what?
> >>> By the time anyone is doing that, most of the really hard work
> >>> has been done.
> >>
> >> Porting a compiler like GCC or LLVM from a similar supported ISA
> >> may not be extraordinarily difficult (but I suspect such still
> >> involves a substantial investment in time). Undergraduates often
> >> have more resources and clearer guidelines than a relatively
> >> isolated self-taught person.
> >
> > Certainly. But just because someone is clever and does a thing
> > that does not a) imply that that person is qualified to work at
> > a higher level, or b) that they are an expert at the thing.
> >
> > One recognizes an undergraduate education as the beginning of
> > one's educational journey (be it followed by further study in an
> > academic context or a professional context), not the end.
> An undergraduate education was beyond the end for me. Despite having
> taught at the undergrad and graduate levels, my only diploma shows that
> I'm a proud graduate of Deer Isle High School. Graduated third in my
> class, mind you - of ten.
>
> Over the years I've hired a fair number of technical people. I've always
> had the policy to impose no recruiting requirement that I myself could
> not satisfy. However, there are some jobs I would actively seek out PhDs
> for, because sometimes you want someone with a demonstrated capacity to
> slog through interminable crap.
<
A long time ago, at a cash register plant in rural Ohio, we were writing cash
register applications in 8085 assembly language. The company policy was
basically, we would hire anyone who would show up and attempt to work
both on the technical side and on the manufacturing side. We also had a
policy that if you were not proficient at your job in 6 months we would add
training and apprenticeships and if you were still not descent at the job
you got laid off. Everyone knew this going in and out.
<
One day I interviewed a guy for a position on the BASIC interpreter team
we were building. His current profession was driving a Pepsi truck. He
had never participated in any STEM activities in his life, and had dropped
out of his residency in the 3rd year because he could no longer deal with
watching people die.
<
After a few weeks, he ended up being one of our best programmers we had
EVER hired.
<
So much for resumés..........

On 6/11/2023 3:48 PM, MitchAlsup wrote:
> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>> On 6/5/2023 4:12 AM, Dan Cross wrote:
>>> In article <u5ifdv$s3i$1...@dont-email.me>,
>>> Paul A. Clayton <paaron...@gmail.com> wrote:
>>>> On 5/29/23 3:27 PM, Dan Cross wrote:
>>>>> In article <2023May2...@mips.complang.tuwien.ac.at>,
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
>>>>>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>>>>>
>>>>>>> I haven't a clue. However, most undergrads who take an
>>>>>>> architecture course do about the same.
>>>>>>
>>>>>> Implement a new architecture in an FPGA and get it to run Doom (which
>>>>>> also means retargeting a compiler for his architecture)? I very much
>>>>>> doubt it.
>>>>
>>>> I am impressed by his accomplishments. I wish the world would
>>>> better exploit such human resources. He obviously has
>>>> psychological issues (autism has been mentioned) which would make
>>>> extracting the value more difficult, but he seems intelligent and
>>>> *able to accomplish things*.
>>>
>>> It may be insensitive, but I don't really care what his problem
>>> is, and I plonked him.
>>>
>>>>> Actually, I really don't think that is that far off. Maybe they
>>>>> won't port a compiler or a reasonably large game, but so what?
>>>>> By the time anyone is doing that, most of the really hard work
>>>>> has been done.
>>>>
>>>> Porting a compiler like GCC or LLVM from a similar supported ISA
>>>> may not be extraordinarily difficult (but I suspect such still
>>>> involves a substantial investment in time). Undergraduates often
>>>> have more resources and clearer guidelines than a relatively
>>>> isolated self-taught person.
>>>
>>> Certainly. But just because someone is clever and does a thing
>>> that does not a) imply that that person is qualified to work at
>>> a higher level, or b) that they are an expert at the thing.
>>>
>>> One recognizes an undergraduate education as the beginning of
>>> one's educational journey (be it followed by further study in an
>>> academic context or a professional context), not the end.
>> An undergraduate education was beyond the end for me. Despite having
>> taught at the undergrad and graduate levels, my only diploma shows that
>> I'm a proud graduate of Deer Isle High School. Graduated third in my
>> class, mind you - of ten.
>>
>> Over the years I've hired a fair number of technical people. I've always
>> had the policy to impose no recruiting requirement that I myself could
>> not satisfy. However, there are some jobs I would actively seek out PhDs
>> for, because sometimes you want someone with a demonstrated capacity to
>> slog through interminable crap.
> <
> A long time ago, at a cash register plant in rural Ohio, we were writing cash
> register applications in 8085 assembly language. The company policy was
> basically, we would hire anyone who would show up and attempt to work
> both on the technical side and on the manufacturing side. We also had a
> policy that if you were not proficient at your job in 6 months we would add
> training and apprenticeships and if you were still not descent at the job
> you got laid off. Everyone knew this going in and out.
> <
> One day I interviewed a guy for a position on the BASIC interpreter team
> we were building. His current profession was driving a Pepsi truck. He
> had never participated in any STEM activities in his life, and had dropped
> out of his residency in the 3rd year because he could no longer deal with
> watching people die.

If by residency, you mean medical residency, then he must have graduated
medical school, which means he had a fair number of science classes (the
S in STEM), and just having been admitted to medical school implies a
pretty smart guy who can learn new things well, so

> After a few weeks, he ended up being one of our best programmers we had
> EVER hired.

Not surprising.

> <
> So much for resumés..........

It seems his resume actually told you a lot about his intelligence,
ability to learn, ability to reason well, willingness to work hard, etc.

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

On Monday, June 12, 2023 at 12:45:24 AM UTC-4, Stephen Fuld wrote:
> On 6/11/2023 3:48 PM, MitchAlsup wrote:
> > On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
> >> On 6/5/2023 4:12 AM, Dan Cross wrote:
> >>> In article <u5ifdv$s3i$1...@dont-email.me>,
> >>> Paul A. Clayton <paaron...@gmail.com> wrote:
> >>>> On 5/29/23 3:27 PM, Dan Cross wrote:
> >>>>> In article <2023May2...@mips.complang.tuwien.ac.at>,
> >>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>>>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
> >>>>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
> >>>>>>>> How many people have done much better with their hobby CPU ISA projects?...
> >>>>>>>
> >>>>>>> I haven't a clue. However, most undergrads who take an
> >>>>>>> architecture course do about the same.
> >>>>>>
> >>>>>> Implement a new architecture in an FPGA and get it to run Doom (which
> >>>>>> also means retargeting a compiler for his architecture)? I very much
> >>>>>> doubt it.
> >>>>
> >>>> I am impressed by his accomplishments. I wish the world would
> >>>> better exploit such human resources. He obviously has
> >>>> psychological issues (autism has been mentioned) which would make
> >>>> extracting the value more difficult, but he seems intelligent and
> >>>> *able to accomplish things*.
> >>>
> >>> It may be insensitive, but I don't really care what his problem
> >>> is, and I plonked him.
> >>>
> >>>>> Actually, I really don't think that is that far off. Maybe they
> >>>>> won't port a compiler or a reasonably large game, but so what?
> >>>>> By the time anyone is doing that, most of the really hard work
> >>>>> has been done.
> >>>>
> >>>> Porting a compiler like GCC or LLVM from a similar supported ISA
> >>>> may not be extraordinarily difficult (but I suspect such still
> >>>> involves a substantial investment in time). Undergraduates often
> >>>> have more resources and clearer guidelines than a relatively
> >>>> isolated self-taught person.
> >>>
> >>> Certainly. But just because someone is clever and does a thing
> >>> that does not a) imply that that person is qualified to work at
> >>> a higher level, or b) that they are an expert at the thing.
> >>>
> >>> One recognizes an undergraduate education as the beginning of
> >>> one's educational journey (be it followed by further study in an
> >>> academic context or a professional context), not the end.
> >> An undergraduate education was beyond the end for me. Despite having
> >> taught at the undergrad and graduate levels, my only diploma shows that
> >> I'm a proud graduate of Deer Isle High School. Graduated third in my
> >> class, mind you - of ten.
> >>
> >> Over the years I've hired a fair number of technical people. I've always
> >> had the policy to impose no recruiting requirement that I myself could
> >> not satisfy. However, there are some jobs I would actively seek out PhDs
> >> for, because sometimes you want someone with a demonstrated capacity to
> >> slog through interminable crap.
> > <
> > A long time ago, at a cash register plant in rural Ohio, we were writing cash
> > register applications in 8085 assembly language. The company policy was
> > basically, we would hire anyone who would show up and attempt to work
> > both on the technical side and on the manufacturing side. We also had a
> > policy that if you were not proficient at your job in 6 months we would add
> > training and apprenticeships and if you were still not descent at the job
> > you got laid off. Everyone knew this going in and out.
> > <
> > One day I interviewed a guy for a position on the BASIC interpreter team
> > we were building. His current profession was driving a Pepsi truck. He
> > had never participated in any STEM activities in his life, and had dropped
> > out of his residency in the 3rd year because he could no longer deal with
> > watching people die.
> If by residency, you mean medical residency, then he must have graduated
> medical school, which means he had a fair number of science classes (the
> S in STEM), and just having been admitted to medical school implies a
> pretty smart guy who can learn new things well, so
> > After a few weeks, he ended up being one of our best programmers we had
> > EVER hired.
> Not surprising.
>
>
> > <
> > So much for resumés..........
>
> It seems his resume actually told you a lot about his intelligence,
> ability to learn, ability to reason well, willingness to work hard, etc.
>
>
>
I think one must be careful not to put too much weight on resumes or job
adverts. It is very important to meet in person and get details. A good
resume just gets one in the door. Many people can have written great
sounding resumes. And just what is the job exactly?

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

MitchAlsup wrote:
> On Saturday, June 10, 2023 at 2:57:37 PM UTC-5, Paul A. Clayton wrote:
>> On 5/29/23 9:07 PM, MitchAlsup wrote:
>>> On Monday, May 29, 2023 at 7:07:58 PM UTC-5, Paul A. Clayton wrote:
>> [snip]
>>>> While *some* of that is bloat from the print/PDF format which
>>>> encourages replication of information and page breaks (e.g., a
>>>> brief look noted that instruction descriptions start at the top of
>>>> a page) and some comes from how the information is organized, a
>>>> *lot* seems to be from "essential complexity".
>>>
>>> I am of the opinion that each instruction should be on its own page
>>> (or set of pages). I am further of the opinion that if you need more
>>> than 2 pages to describe the instruction, you should provide a
>>> summary on one page and a forward pointer to where you discuss
>>> the topic fully and in scope with all the other instructions involved.
>>
>> I am of the opinion that most documentation should not use a
>> single-view print-oriented format (like PDF). (I do admit that
>> spatial recognition is important for re-referencing content,
>> especially when one cannot think of the appropriate search terms
>> but has a memory of "landmarks" and general location. I suspect
>> there are ways to provide similar memory keys without requiring
>> consistent pagination.)
> <
> Is rampant cross reference links not sufficient here ?
>>
>> While humans can filter consistent unimportant details when, e.g.,
>> each instruction description has the same basic format, I suspect
>> that supporting multiple views of the information might be more
>> useful.
>>
>> When viewing documentation on a monitor, one might prefer the
>> ability to optionally inline common material rather than use a
>> link. (A PDF viewer can provide a preview of the link target, but
>> this preview will be sized according to a general concept of
>> utility and not consider the content of the linked material.)
> <
> I was thinking more about haw a Supervisor Call and a Supervisor
> return need a quick definition in ISA and then the pair of them plus
> interrupts and exceptions all together require a complete chapter
> to annotate how they work together in the "system" and how they
> interact over a period of time spanning multiple instructions
> where there is potential for exception and interrupts to transpire
> "all at the same time". Where chapter is on the order of 20 pages.
>>
>> Maybe I am strange and/or mistrained in losing focus from link
>> following. (I can see how making content visible or hidden
>> dynamically could further hurt the "spatial memory", but for
>> shortish content such might be better than a link.)
> <
> You need a reader where you can follow a link and return whence
> you followed.
> <
> But (the BIG but) all sufficiently well described architectures end
> up in the position that the reader has to read all the documents in
> order to be in a position to read the documents with understanding.
> <
> At a place of employment, one needs a ceiling height by 40 foot
> long "white board" to draw a schematic for the µArchitecture in
> sufficient detail to find and reason about (then correct) the
> "schematic". Scrolling around on a screen with a schematic that
> is 100×screen sizes big is not workable....
>>
>> (I do not know what the electronic display version would be for
>> having two or more books open on a desk along with various sheets
>> of notes. Tabbed browsing provides some of this functionality
>> [though I suspect head turning to change context has some
>> psychological impact, especially if the side content has a less
>> comfortable viewing position which naturally draws one back to the
>> comfortable view of the main content], but the order/arrangement
>> of tabs is unlikely to mesh with one's mental model. I suspect
>> this is related to some people's preference for multiple screens;
>> a computer could easily change the display [virtual desktops have
>> been around for quite a while] but the navigation seems to be less
>> "natural" and more intentional [peripheral vision could also be a
>> factor].)
>>
>>> Luckily for me, I only have 61 instructions....the rest of the ISA
>>> manual discusses Who, What, Where, When, and WHY.
>>
>> Well, that also depends on how one counts instructions. E.g., ADD
>> is documented as one My 66000 instruction but could easily be
>> counted as 33 instructions, the 16-bit immediate form (which seems
>> to always be unsigned, i.e., not overflow) and 32 forms using two
>> input encoding with I, S1, S2, S, and d bits specifying which of
>> the 32 forms is used. (I am not criticizing. I think this avoids
>> unnecessary complexity compared to
> <
> There are 61 spellings the assembly language programmer has
> to memorize to capture the whole instruction set in his head.
> {Not to mention there is no SUB instruction, or NEG, or COMP
> instruction, no FMULSUB, and a host of other "spellings".} in
> My 66000 the OpCode describes the calculation, those other 32
> forms describe the routing of operand to the calculation.
>>
>>> I am of the opinion that certain groups of instructions are deserving
>>> of an entire chapter by themselves in a different book--such as multi-
>>> precision arithmetic, ATOMIC events, the ABI--ENTER and EXIT, ...
>>> <
>>> I am of the opinion that certain corners of an architecture are deserving
>>> of an entire book (say 200± pages)--such as: systems organization,
>>> interconnects, protocols, BOOT, messaging, interrupts, traps, exceptions
>>> and any special sequencing.
>>
>> In a non-print medium, the concept of "book" may be less well
>> defined. While ebook software seems (like PDF viewers) to handle
>> large documents poorly, I do not think this is essential to the
>> fuzzing/coherence of the concept of "volume"/"book".
>> Distribution/packaging unit may be a reasonable definition for
>> "book", but size if often much less of a consideration than for
>> physical books.
> <
> I (do) understand what you are getting at, but (as yet) we don't
> really have a way of having 89 views into a document on 89 windows
> so we can see all the nuances that one complicated instruction
> brings to the party (for better or worse). {{See 10 minutes before
> the end of Lawnmower Man}}
>>
>>> I currently have a book for each :: ISA, unprivileged Software Programming
>>> model, Systems architecture and programming model, 1-wide in-order
>>> µArchitecture, and ½ of a 6-wide GBOoO µArchitecture. All of this is under
>>> 1,000 pages total.
>>> <
>>> I also believe that one writes a document to 80% completion level,
>>> then starts moving stuff around until it flows better, then finishes
>>> the last 20%. The part of moving stuff around takes 25% of the total
>>> time.
>>
>> And presumably moving stuff around also influences the content
>> itself.
> <
> absolutely--and you would not have been able to "see" it without
> said movement.
> <
>> Gaining an understanding of how content relates to other
>> content presumably leads one to better management of completeness,
>> clarity, and conciseness.
> <
> And use the same word with the same meaning everywhere across
> 4-10 documents.

Just doing it consistently within the single ieee754-2019 document took
some weeks...

Terje

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

On 6/11/2023 3:48 PM, MitchAlsup wrote:
> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>> On 6/5/2023 4:12 AM, Dan Cross wrote:
>>> In article <u5ifdv$s3i$1...@dont-email.me>,
>>> Paul A. Clayton <paaron...@gmail.com> wrote:
>>>> On 5/29/23 3:27 PM, Dan Cross wrote:
>>>>> In article <2023May2...@mips.complang.tuwien.ac.at>,
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
>>>>>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>>>>>
>>>>>>> I haven't a clue. However, most undergrads who take an
>>>>>>> architecture course do about the same.
>>>>>>
>>>>>> Implement a new architecture in an FPGA and get it to run Doom (which
>>>>>> also means retargeting a compiler for his architecture)? I very much
>>>>>> doubt it.
>>>>
>>>> I am impressed by his accomplishments. I wish the world would
>>>> better exploit such human resources. He obviously has
>>>> psychological issues (autism has been mentioned) which would make
>>>> extracting the value more difficult, but he seems intelligent and
>>>> *able to accomplish things*.
>>>
>>> It may be insensitive, but I don't really care what his problem
>>> is, and I plonked him.
>>>
>>>>> Actually, I really don't think that is that far off. Maybe they
>>>>> won't port a compiler or a reasonably large game, but so what?
>>>>> By the time anyone is doing that, most of the really hard work
>>>>> has been done.
>>>>
>>>> Porting a compiler like GCC or LLVM from a similar supported ISA
>>>> may not be extraordinarily difficult (but I suspect such still
>>>> involves a substantial investment in time). Undergraduates often
>>>> have more resources and clearer guidelines than a relatively
>>>> isolated self-taught person.
>>>
>>> Certainly. But just because someone is clever and does a thing
>>> that does not a) imply that that person is qualified to work at
>>> a higher level, or b) that they are an expert at the thing.
>>>
>>> One recognizes an undergraduate education as the beginning of
>>> one's educational journey (be it followed by further study in an
>>> academic context or a professional context), not the end.
>> An undergraduate education was beyond the end for me. Despite having
>> taught at the undergrad and graduate levels, my only diploma shows that
>> I'm a proud graduate of Deer Isle High School. Graduated third in my
>> class, mind you - of ten.
>>
>> Over the years I've hired a fair number of technical people. I've always
>> had the policy to impose no recruiting requirement that I myself could
>> not satisfy. However, there are some jobs I would actively seek out PhDs
>> for, because sometimes you want someone with a demonstrated capacity to
>> slog through interminable crap.
> <
> A long time ago, at a cash register plant in rural Ohio, we were writing cash
> register applications in 8085 assembly language. The company policy was
> basically, we would hire anyone who would show up and attempt to work
> both on the technical side and on the manufacturing side. We also had a
> policy that if you were not proficient at your job in 6 months we would add
> training and apprenticeships and if you were still not descent at the job
> you got laid off. Everyone knew this going in and out.
> <
> One day I interviewed a guy for a position on the BASIC interpreter team
> we were building. His current profession was driving a Pepsi truck. He
> had never participated in any STEM activities in his life, and had dropped
> out of his residency in the 3rd year because he could no longer deal with
> watching people die.
> <
> After a few weeks, he ended up being one of our best programmers we had
> EVER hired.
> <
> So much for resumés..........

Best programmer at PRC was an empty-nest woman hired as an assistant to
the office manager. No STEM, but dual PhDs - one was French Medieval
Literature and I forget the other, but similarly obscure.

Job prereqs are just a device to let HR be lazy.