On Thursday, March 3, 2022 at 6:41:58 AM UTC-6, Ivan Godard wrote:
> On 3/3/2022 3:05 AM, Thomas Koenig wrote:
> > Ivan Godard <iv...@millcomputing.com> schrieb:
> >> On 3/2/2022 9:40 AM, Anton Ertl wrote:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>>>> Ivan Godard <iv...@millcomputing.com> writes:
> >>>>>> Declarable (!) precedence was a disaster
> >>>>>> in A68 - what's the precedence of left circular shift?
> >>>>>
> >>>>> IMO the general concept of precedence is a disaster. You can do
> >>>>> implicit parenthesizing between well-established pairs of operators
> >>>>> (e.g., a+b*c,
> >>>>
> >>>> You should.
> >>>>
> >>>> FORTRAN pretty much settled this question. Evaluating a formula
> >>>> in any other way is a desaster.
> >>>
> >>> What disaster would ensue from not accepting a+b*c and instead
> >>> requiring a+(b*c)? However, it seems to me that the relative
> >>> precedences of + and * and widely-enough known that accepting a+b*c
> >>> instead does not cause problems.
> >>
> >> Well, if we are going to match mathematic practice that should be
> >> "a+bc"; there have been historical efforts toward that sort of thing.
<
It is about time that programming languages use the multiply symbol
× instead of the * symbol. Even x×x parses with the eye.
<
> >
> > Restricting the user to single-letter variables would not be such
> > a great idea, I think.
> Was highly successful in the original BASIC.
<
Would work great in a 10,000,000 line program !

On Thursday, March 3, 2022 at 8:48:23 AM UTC-6, EricP wrote:
> Anton Ertl wrote:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >> As written elsethread, both ARM and IBM deprecated multiple store
> >> and load instructions - ARM by not including them in aarch64, IBM
> >> by restricting them in POWER to 32-bit size and to big-endian only.
> >> In other words, legacy code. POWER9 microcodes it, which incurs
> >> a significant penalty. Mitch explained that it is less a burden
> >> to his My 66000 implementations.
> >>
> >> aarch64 has load and store double instead.
> > ....
> >> Use in a function body is much harder (depending on what exactly
> >> is in the ISA). If you can load/store regiters up to the maximum
> >> register number that you have (POWER) or a register range (My
> >> 66000), you would have to work your whole register allocation
> >> around the load/store multiple instruction. This would be
> >> rather inconvenient, and I suspect that compilers would not use
> >> it.
> >
> > I have certainly seen quite a few load-pair and store-pair
> > instructions in gcc-generated Aarch64 code outside function
> > prologue/epilogue:
> >
> > In the 6008 lines of output from "objdump -d
> > engine/engine-fast-ll-reg.o" (pretty much a single large function),
> > ldp occurs 133 times (among them 24 accesses through sp) and stp
> > occurs 76 times (17 accesses through sp). The accesses through sp are
> > probably around function calls, the others are other pairwise accesses
> > that the compiler could combine.
> >
> > So I expect that efficient load-multiple or store-multiple
> > instructions would also be used by gcc; the question is how often
> > there would be cases with more than two registers. Apparently not
> > enough to make the Aarch64 architects add instructions for that.
> >
> > The benefit of the load-pair and store-pair instructions over a pair
> > of loads/stores is that they reduce load/store-unit contention; of
> > course, the RISC-V answer to that is that the decoder can combine such
> > a pair into one pairwise micro-instruction.
> The register save set size sets the minimum width of a number of resources,
> the number of register read and write ports,
> width that LSQ should handle including store-load forwarding.
> With LDP/STP 2*64 it should not be a hardship even for a minimal
> implementation.
>
> For LDM/STM to run at full speed it would need to operate on a
> full 64B cache line, 8 register wide datapath to/from memory. That's
> - 8 read ports on the rename tables
<
A 6-wide machine already has 12-14 of these ports.
<
> - 8 read and 8 write register file ports
<
A 6-wide reservation station machine already has 12-14 of these
<
> - 8 operand buses to LSQ, store-load forwarding,
<
A 6-wide machine already has 12-read 6-write.
<
> (possibly also internally forwarding withing the LSQ itself)
> and input operand forwarding from FU results
> - 8 result buses from LSQ, with output forwarding
<
A 6-wide machine already has 6 of these.
<
> (plus possibly internal forwarding withing the LSQ itself)
> - 512 bit datapath to/from cache with alignment shifters for line straddles.
<
You are suggesting that these instructions occupy 1 instruction
in the stream, and are issued with another 5 instructions which
are completely dependent on the completion of the LDM or STM.
>
> and it would still need some kind of microcode sequencer for
> when there was more than 8 save/restore registers in a set.

On Thursday, March 3, 2022 at 9:09:34 AM UTC-6, Anton Ertl wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >Anton Ertl wrote:
> >> And I don't think it's just the orthogonal features that can profit
> >> from this effect. However, I guess that the orthogonal features have
> >> additional honeypot potential because they are theoretically more
> >> widely useful than non-orthogonal features like the 8086s LODS
> >> instruction.
> >
> >Those original string ops on the 8088 were absolutely crucial, simply
> >because they allowed us to write extremely compact code.
> >
> >On a CPU where all bytes read or stored (including instruction bytes
> >which usually would dominate) would take 4 cycles, using those
> >single-byte opcodes with auto-increment/decrement was the difference
> >between "too slow" and "usable".
> I am wondering if this is a demonstration of the feeling of
> achievement that creates an attachment to these features.
>
> What was the proportion of these instructions in production code,
> statically and dynamically?
<
We found this to be an illusion early in RISC.
<
MOV *[SP-],R1
MOV *[SP-],R2
MOV *[SP-],R3
<
Would perform faster in a pipelined machine as:
<
ST R1,[SP]
ST R2,[SP+4]
ST R3,[SP+8]
SUB SP,SP,12
<
Now, instead of 3 instructions dependent on each other you have
4 instructions with no dependencies. It is the lack of dependencies
that clears the way to perform all of the STs in a single cycle.
>
> Looking at an example, here's a table of implementations of NEXT
> (virtual machine instruction dispatch) in various assembly languages:
>
> PDP-11 6809 8086 8086'
> next: mov (ip)+,w ldx ,y++ lods lods ax
> mov bx,ax mov bx,ax
> next1: jmp @(w)+ jmp [,x] mov dx,bx jmp word ptr[bx]
> inc dx
> jmp word ptr[bx]
>
> IP and W are aliases for PDP-11 registers; IP/Y/SI is the virtual
> machine instruction pointer.
>
> 8086 is what's in the table (originally from the fig-Forth listing,
> like the PDP-11 and the 6809 variants), 8086' is a cleaned-up version
> that does not pull stuff up from some of the possible jump targets.
>
> So we see here that the implicit registers of lods combined with the
> limitations of usable registers in the jmp conspire to require an
> additional mov instruction. Not sure if this really saves code size
> compared to the 6809 or PDP-11.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 3/3/2022 5:45 AM, aph@littlepinkcloud.invalid wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 3/2/2022 3:24 AM, aph@littlepinkcloud.invalid wrote:
>>> Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>>>>
>>>> (32 bit ARM is interesting as it was designed to be nice to program
>>>> in assembly, a consideration not normally part of instruction set
>>>> design these days)
>>>
>>> That's an interesting point. In my experience 64-bit ARM is as nice to
>>> program in assembly, at least as far as the set of base instructions
>>> goes, even though there are more instructions.
>>>
>>> I also believe that if an instruction set is nice to program in
>>> assembly, it's also nice to write a code generator for.
>>
>> Wasn't one of the results from the studies of generated code,that
>> was used to justify RISC, that "nice to write assembly in" features
>> such as complex and orthogonal addressing modes just weren't used in
>> generated code?
>
> Are complex addressing modes nice to write assembly in, though? I've
> never found it to be so. I think the problem identified with IBM 370
> was that many of the addressing modes weren't being used by compilers
> or by hand-cranked code, but I can't find any data for that one way or
> the other.
>
> I can see the point of orthogonality, as long as it's not extended too
> far. Of course no-one actually wants to have to use, say, a dedicated
> pair of registers to do a multiply.
>

There is likely some room for debate here.
Some people seemingly consider anything much beyond (Rb,Disp) to be
complex...

IME, ranking is roughly:
(Rb,Disp):
Very common
(Rb,Ri):
Also very common (2nd place)
(Scale matches access size)
(Rb,Ri*Sc, Disp)
Uncommon, Harder to make use of.

Then, "danger zone":
@Rb+, @-Rb: Uncommon and requires an extra write port (1)
@+Rb, @Rb-: Likewise
@@Rb: Devil crap.
...

1: Though, in premise, these can map to C's "*ptr++" and "*--ptr" modes
and similar, the occurrence of "*ptr++" in C isn't common enough to
really justify having a dedicated instruction for it (when the increment
or decrement can often be run in parallel with another instruction).

While using PC or GBR or similar as a base register are useful, I will
not consider them as separate address modes. Depending on the ISA asd
ABI design, these may end up fairly common (namely for loading/storing
global variables).

Other semi-common cases are the ability to encode:
LEA (Rb, Disp), Rn //More Common
LEA.x (Rb, Ri), Rn //Less Common

This can almost be subsumed into ADD, except:
It is useful to be able to encode PC or GBR or similar as a base
If these are not available as GPRs
If pointers are "special" in some way, a plain ADD may not be usable.

There are pros/cons, I am now leaning on the side of things that PC, LR,
SP, and GBR, are commonly referenced enough in other instructions that
it makes sense to have them available via the GPR encoding (assuming a
32 or 64 register design).

A Zero register is also useful, but one trick here is to have a register
be interpreted as either PC or Zero depending on which register port it
is accessed from (any instruction which tries to use PC as an Index or
second argument will always get Zero).

One can also debate the merits of instructions using PC and similar as a
target to encode branch instructions and similar.
BRA Disp -> ADD PC, Disp, PC //Special
BSR Disp -> ADD PC, Disp, LR //Special
RTS -> ADD LR, ZR, PC //Special
MOV Rm, Rn -> OR Rm, ZR, Rn //Pseudo
...

....

> Andrew.

Anton Ertl wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> Anton Ertl wrote:
>>> And I don't think it's just the orthogonal features that can profit
>>> from this effect. However, I guess that the orthogonal features have
>>> additional honeypot potential because they are theoretically more
>>> widely useful than non-orthogonal features like the 8086s LODS
>>> instruction.
>>
>> Those original string ops on the 8088 were absolutely crucial, simply
>> because they allowed us to write extremely compact code.
>>
>> On a CPU where all bytes read or stored (including instruction bytes
>> which usually would dominate) would take 4 cycles, using those
>> single-byte opcodes with auto-increment/decrement was the difference
>> between "too slow" and "usable".
>
> I am wondering if this is a demonstration of the feeling of
> achievement that creates an attachment to these features.
>
> What was the proportion of these instructions in production code,
> statically and dynamically?
>
> Looking at an example, here's a table of implementations of NEXT
> (virtual machine instruction dispatch) in various assembly languages:
>
> PDP-11 6809 8086 8086'
> next: mov (ip)+,w ldx ,y++ lods lods ax
> mov bx,ax mov bx,ax
> next1: jmp @(w)+ jmp [,x] mov dx,bx jmp word ptr[bx]
> inc dx
> jmp word ptr[bx]
>
> IP and W are aliases for PDP-11 registers; IP/Y/SI is the virtual
> machine instruction pointer.
>
> 8086 is what's in the table (originally from the fig-Forth listing,
> like the PDP-11 and the 6809 variants), 8086' is a cleaned-up version
> that does not pull stuff up from some of the possible jump targets.
>
> So we see here that the implicit registers of lods combined with the
> limitations of usable registers in the jmp conspire to require an
> additional mov instruction. Not sure if this really saves code size
> compared to the 6809 or PDP-11.

No, what this proves is that 8088 wasn't a very good vehicle for Forth,
in order to get that "usefully fast" code we had to remove all the
housekeeping/overhead code required by an interpreter.

I.e. my 8088 word count code assumed that space, (CR)LF and alphanumeric
bytes would dominate and unrolled the "find end of current word" code to
minimize the number of tests and taken branches:

start_word:
inc dx
in_word:
lodsb
cmp al,' '
jbe leave_word
lodsb
cmp al,' '
jbe leave_word
lodsb
cmp al,' '
jbe leave_word
lodsb
cmp al,' '
ja in_word

leave_word:
jb control_char
white_space:
lodsb
cmp al,' '
ja start_word
je white_space
control_char:
cmp al,8 ;; Tab?
je white_space

etc.

This code got around 7 total code+data bytes per byte counted, so it
handled about 144 KB/s.

Using my 16-bit Pentium code instead I would have needed a few more bus
operations/byte but not horribly worse:

add ax,dx
mov dx,table[bx]
mov bl,es:[di]
mov di,[si+OFFS]

add ax,dx
mov dx,table[bx+32]
mov bl,es:[di]
mov di,[si+OFFS+2]

The code above counts chars/words/lines in 4 input bytes, it needs 10
bytes loaded from lookup tables as well as 26 code bytes, so 36 bytes
total or 9 bytes/character counted, so it would handle about 115 KB/s.

On its Pentium target however, the speed increased to 40 MB/s on a 60
MHz CPU, i.e. about 14 x higher clock rate but 300 x higher performance.

Where 8088 did shine was in byte processing loops which would fit
directly into the intended register allocation, i.e. SI/DI for
source/dest, DX for port IO, CX/CL for shift & loop count, BX for table
lookups and AX as the single accumulator.

Terje

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

On Thursday, March 3, 2022 at 1:07:21 PM UTC-6, BGB wrote:
> On 3/3/2022 5:45 AM, a...@littlepinkcloud.invalid wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
> >> On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
> >>> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> >>>>
> >>>> (32 bit ARM is interesting as it was designed to be nice to program
> >>>> in assembly, a consideration not normally part of instruction set
> >>>> design these days)
> >>>
> >>> That's an interesting point. In my experience 64-bit ARM is as nice to
> >>> program in assembly, at least as far as the set of base instructions
> >>> goes, even though there are more instructions.
> >>>
> >>> I also believe that if an instruction set is nice to program in
> >>> assembly, it's also nice to write a code generator for.
> >>
> >> Wasn't one of the results from the studies of generated code,that
> >> was used to justify RISC, that "nice to write assembly in" features
> >> such as complex and orthogonal addressing modes just weren't used in
> >> generated code?
> >
> > Are complex addressing modes nice to write assembly in, though? I've
> > never found it to be so. I think the problem identified with IBM 370
> > was that many of the addressing modes weren't being used by compilers
> > or by hand-cranked code, but I can't find any data for that one way or
> > the other.
> >
> > I can see the point of orthogonality, as long as it's not extended too
> > far. Of course no-one actually wants to have to use, say, a dedicated
> > pair of registers to do a multiply.
> >
> There is likely some room for debate here.
> Some people seemingly consider anything much beyond (Rb,Disp) to be
> complex...
>
>
> IME, ranking is roughly:
> (Rb,Disp):
> Very common
> (Rb,Ri):
> Also very common (2nd place)
> (Scale matches access size)
> (Rb,Ri*Sc, Disp)
> Uncommon, Harder to make use of.
>
My 66000 has scale encoded in one place and width encoded in another.
<
As to utility: although they only make up 2%-3% of instruction stream
they pretty much convert 2 instructions into 1 so they represent 2%-3%
performance gain. That may not be enough to make the cut in some
designs, and I disparage them not. On the other hand, while doing x86-64
I saw how little HW it took to do them, and how much it helped when
you really needed, and it saved a register when they were scant, too.
<
>
>
> Then, "danger zone":
> @Rb+, @-Rb: Uncommon and requires an extra write port (1)
> @+Rb, @Rb-: Likewise
> @@Rb: Devil crap.
> ...
These require all sorts of compromise, including more register write
ports, more RAW dependencies, and are generally hard to pipeline.
In effect: you may not have shot yourself in the foot, but you took an
ice pick and drove it through nonetheless.
>
> 1: Though, in premise, these can map to C's "*ptr++" and "*--ptr" modes
> and similar, the occurrence of "*ptr++" in C isn't common enough to
> really justify having a dedicated instruction for it (when the increment
> or decrement can often be run in parallel with another instruction).
>
>
> While using PC or GBR or similar as a base register are useful, I will
> not consider them as separate address modes. Depending on the ISA asd
> ABI design, these may end up fairly common (namely for loading/storing
> global variables).
>
> Other semi-common cases are the ability to encode:
> LEA (Rb, Disp), Rn //More Common
<
This is often used as a prelude to MEM Rd,[Rn+Ri<<s] when you don't
have 2-registers+displacement memory references.
<
> LEA.x (Rb, Ri), Rn //Less Common
<
What does the ".x" signify ?
>
> This can almost be subsumed into ADD, except:
> It is useful to be able to encode PC or GBR or similar as a base
> If these are not available as GPRs
> If pointers are "special" in some way, a plain ADD may not be usable.
<
You might also have different overflow/saturation conditions with
ADD.
>
>
> There are pros/cons, I am now leaning on the side of things that PC, LR,
> SP, and GBR, are commonly referenced enough in other instructions that
> it makes sense to have them available via the GPR encoding (assuming a
> 32 or 64 register design).
<
IP is almost never used as an operand to other than memory reference
instructions. Return address R0, SP R31are actual registers, So is FP R30,
and Thread_Local_Data R16.
>
> A Zero register is also useful, but one trick here is to have a register
> be interpreted as either PC or Zero depending on which register port it
> is accessed from (any instruction which tries to use PC as an Index or
> second argument will always get Zero).
>
In my opinion wasting a register to contain zero is simply a waste.
So, I have STx #0,[Rbase+Rindex<<scale+Disp] and MOV Rd,#imm16
when you really have to have it.
>
> One can also debate the merits of instructions using PC and similar as a
> target to encode branch instructions and similar.
> BRA Disp -> ADD PC, Disp, PC //Special
> BSR Disp -> ADD PC, Disp, LR //Special
> RTS -> ADD LR, ZR, PC //Special
> MOV Rm, Rn -> OR Rm, ZR, Rn //Pseudo
<
I recently added messages to My 66000 ISA. The caller sends a number of
registers to the called (in accordance with ABI) and whether or not the
called can access callers memory through indirection. Called runs in a
different address space, with different privilege, under a potentially
different Guest OS. Here Return Address = 0x01 (a magic cookie).
<
When called executes a RET instruction, control returns to caller in his
own address space, at his privilege, in a core of his affinity,...
<
The called "subroutine" cannot tell that he was invoked by the message
or called locally, except by looking at RA being the magic cookie. This
works if safe stack is in use or not on both sides.
<
Indirection is my variant of PDP-11/70s MOV from and MOV to (alternate
address space). I even set it up to use the ASID of the caller when accessing
caller's memory via indirection.
<
Total number of instructions added: 2: Message Call, and Message Send.
Total number of instructions modified: 2: RET and EXIT detect magic
cookie.
<
> ...
>
> ...
>
>
> > Andrew.

Ivan Godard wrote:
> On 3/3/2022 5:07 AM, Anton Ertl wrote:
>> Ivan Godard <ivan@millcomputing.com> writes:
>>> On 3/3/2022 3:40 AM, Anton Ertl wrote:
>>> <snip>
>>>
>>>> My argument is actually that the normal case should be to require
>>>> explicit parentheses, and we can make a few exceptions to that rule
>>>> (but they should really be few).
>>>
>>> But (as noted by several commenters here) that leads to informal
>>> parenthesizing everything in the name of readability and safety.
>>
>> I have no idea what "informal parenthesizing" is supposed to mean.  If
>> you mean that nobody writes "a+b*c", I think you are wrong.  But of
>> course, having zero exceptions to the rule of requiring explicit
>> parentheses is fine with me.
>>
>> - anton
>
> "informal parenthesizing": syntactic rules required by convention but
> not by formal syntax.

That's "informational" not "informal"!

Terje

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

MitchAlsup wrote:
> On Thursday, March 3, 2022 at 8:48:23 AM UTC-6, EricP wrote:
>> Anton Ertl wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>> As written elsethread, both ARM and IBM deprecated multiple store
>>>> and load instructions - ARM by not including them in aarch64, IBM
>>>> by restricting them in POWER to 32-bit size and to big-endian only.
>>>> In other words, legacy code. POWER9 microcodes it, which incurs
>>>> a significant penalty. Mitch explained that it is less a burden
>>>> to his My 66000 implementations.
>>>>
>>>> aarch64 has load and store double instead.
>>> ....
>>>> Use in a function body is much harder (depending on what exactly
>>>> is in the ISA). If you can load/store regiters up to the maximum
>>>> register number that you have (POWER) or a register range (My
>>>> 66000), you would have to work your whole register allocation
>>>> around the load/store multiple instruction. This would be
>>>> rather inconvenient, and I suspect that compilers would not use
>>>> it.
>>> I have certainly seen quite a few load-pair and store-pair
>>> instructions in gcc-generated Aarch64 code outside function
>>> prologue/epilogue:
>>>
>>> In the 6008 lines of output from "objdump -d
>>> engine/engine-fast-ll-reg.o" (pretty much a single large function),
>>> ldp occurs 133 times (among them 24 accesses through sp) and stp
>>> occurs 76 times (17 accesses through sp). The accesses through sp are
>>> probably around function calls, the others are other pairwise accesses
>>> that the compiler could combine.
>>>
>>> So I expect that efficient load-multiple or store-multiple
>>> instructions would also be used by gcc; the question is how often
>>> there would be cases with more than two registers. Apparently not
>>> enough to make the Aarch64 architects add instructions for that.
>>>
>>> The benefit of the load-pair and store-pair instructions over a pair
>>> of loads/stores is that they reduce load/store-unit contention; of
>>> course, the RISC-V answer to that is that the decoder can combine such
>>> a pair into one pairwise micro-instruction.
>> The register save set size sets the minimum width of a number of resources,
>> the number of register read and write ports,
>> width that LSQ should handle including store-load forwarding.
>> With LDP/STP 2*64 it should not be a hardship even for a minimal
>> implementation.
>>
>> For LDM/STM to run at full speed it would need to operate on a
>> full 64B cache line, 8 register wide datapath to/from memory. That's
>> - 8 read ports on the rename tables
> <
> A 6-wide machine already has 12-14 of these ports.

Plus 8 rename write ports as it would need to rename 8 registers at once
for each LDM uOp.

> <
>> - 8 read and 8 write register file ports
> <
> A 6-wide reservation station machine already has 12-14 of these

It usually has lots of read ports but not that many write ports.

Also maybe only a subset of the ports are available for load/store
instructions. So issue logic can launch 6 or 8 uOps per clock
but only 2 of them can be to the Load Store Unit.

> <
>> - 8 operand buses to LSQ, store-load forwarding,
> <
> A 6-wide machine already has 12-read 6-write.

Again it may be that only a subset of buses run from RF to LSQ
to avoid having a full blown operand crossbar to all FU.

> <
>> (possibly also internally forwarding withing the LSQ itself)
>> and input operand forwarding from FU results
>> - 8 result buses from LSQ, with output forwarding
> <
> A 6-wide machine already has 6 of these.
> <
>> (plus possibly internal forwarding withing the LSQ itself)
>> - 512 bit datapath to/from cache with alignment shifters for line straddles.
> <
> You are suggesting that these instructions occupy 1 instruction
> in the stream, and are issued with another 5 instructions which
> are completely dependent on the completion of the LDM or STM.

Just exploring the hardware needed to optimize load or store multiple of
up to 32 64-bit registers faster than 32 individual LD or ST instructions,
ideally in 4 clocks. Similar concept to a hardware byte buffer block move.

Cache line is 64B and we would like to pack 8 registers together
in a single load or store operation. Decode sees an LDM/STM with a
register mask or range select of up to 32 registers, and emits 1..4 uOps
each for load or store of up to 8 data registers plus address registers.

Each STM uOp basically takes over the Dispatcher resources,
using all the read ports and buses to move the 0..2 address registers
plus 1..8 data registers to a AGU-LSQ entry.

Each LDM uOp Dispatch is like a regular load in that Dispatcher moves
0..2 address registers to a AGU-LSQ entry. But on completion it takes
over all the result write and forwarding buses for its 1..8 results.

Each set of 8 loaded or stored registers must obey all the usual rules
for store-load forwarding and x86-TSO coherence. This is an expansion
of existing rules since the memory bytes are contiguous though
not necessarily cache aligned.

If the load or store straddles 2 cache lines then it needs a 512-bit shifter
and able to read/update 2 cache lines at once (dual port or odd/even banks).

On 3/3/2022 1:45 PM, MitchAlsup wrote:
> On Thursday, March 3, 2022 at 1:07:21 PM UTC-6, BGB wrote:
>> On 3/3/2022 5:45 AM, a...@littlepinkcloud.invalid wrote:
>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
>>>> On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
>>>>> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>>>>>>
>>>>>> (32 bit ARM is interesting as it was designed to be nice to program
>>>>>> in assembly, a consideration not normally part of instruction set
>>>>>> design these days)
>>>>>
>>>>> That's an interesting point. In my experience 64-bit ARM is as nice to
>>>>> program in assembly, at least as far as the set of base instructions
>>>>> goes, even though there are more instructions.
>>>>>
>>>>> I also believe that if an instruction set is nice to program in
>>>>> assembly, it's also nice to write a code generator for.
>>>>
>>>> Wasn't one of the results from the studies of generated code,that
>>>> was used to justify RISC, that "nice to write assembly in" features
>>>> such as complex and orthogonal addressing modes just weren't used in
>>>> generated code?
>>>
>>> Are complex addressing modes nice to write assembly in, though? I've
>>> never found it to be so. I think the problem identified with IBM 370
>>> was that many of the addressing modes weren't being used by compilers
>>> or by hand-cranked code, but I can't find any data for that one way or
>>> the other.
>>>
>>> I can see the point of orthogonality, as long as it's not extended too
>>> far. Of course no-one actually wants to have to use, say, a dedicated
>>> pair of registers to do a multiply.
>>>
>> There is likely some room for debate here.
>> Some people seemingly consider anything much beyond (Rb,Disp) to be
>> complex...
>>
>>
>> IME, ranking is roughly:
>> (Rb,Disp):
>> Very common
>> (Rb,Ri):
>> Also very common (2nd place)
>> (Scale matches access size)
>> (Rb,Ri*Sc, Disp)
>> Uncommon, Harder to make use of.
>>
> My 66000 has scale encoded in one place and width encoded in another.
> <
> As to utility: although they only make up 2%-3% of instruction stream
> they pretty much convert 2 instructions into 1 so they represent 2%-3%
> performance gain. That may not be enough to make the cut in some
> designs, and I disparage them not. On the other hand, while doing x86-64
> I saw how little HW it took to do them, and how much it helped when
> you really needed, and it saved a register when they were scant, too.
> <

Issue is that one needs to spare two extra bits to encode the separate
scale.

In my case, 32-bit encodings can only do:
MOV.x (Rb, Ri), Rn
Whereas Op64 and Op40x2 can do:
MOV.x (Rb, Ri*Sc, Disp11) //Op64
MOV.x (Rb, Ri*Sc, Disp5) //Op40x2

Though, this is considered part of an ISA extension.

>>
>>
>> Then, "danger zone":
>> @Rb+, @-Rb: Uncommon and requires an extra write port (1)
>> @+Rb, @Rb-: Likewise
>> @@Rb: Devil crap.
>> ...
> These require all sorts of compromise, including more register write
> ports, more RAW dependencies, and are generally hard to pipeline.
> In effect: you may not have shot yourself in the foot, but you took an
> ice pick and drove it through nonetheless.

This is part of why I left them out.

>>
>> 1: Though, in premise, these can map to C's "*ptr++" and "*--ptr" modes
>> and similar, the occurrence of "*ptr++" in C isn't common enough to
>> really justify having a dedicated instruction for it (when the increment
>> or decrement can often be run in parallel with another instruction).
>>
>>
>> While using PC or GBR or similar as a base register are useful, I will
>> not consider them as separate address modes. Depending on the ISA asd
>> ABI design, these may end up fairly common (namely for loading/storing
>> global variables).
>>
>> Other semi-common cases are the ability to encode:
>> LEA (Rb, Disp), Rn //More Common
> <
> This is often used as a prelude to MEM Rd,[Rn+Ri<<s] when you don't
> have 2-registers+displacement memory references.
> <

>> LEA.x (Rb, Ri), Rn //Less Common
> <
> What does the ".x" signify ?

That is the type used to encode the scale used for Ri.
So:
LEA.B (Rb, Ri), Rn // Rn=Rb+Ri
LEA.W (Rb, Ri), Rn // Rn=Rb+Ri*2
LEA.L (Rb, Ri), Rn // Rn=Rb+Ri*4
LEA.Q (Rb, Ri), Rn // Rn=Rb+Ri*8

This detail can be glossed over for the (Rb, Disp) case.

In my case, for XLEA, only the .B encoding was provided in the base ISA,
and the others were provided indirectly via Op64 encodings.

Partly this was because some other encodings occupied the same space
that might have otherwise been used for the other LEA's (and scaled
index LEA being fairly uncommon).

>>
>> This can almost be subsumed into ADD, except:
>> It is useful to be able to encode PC or GBR or similar as a base
>> If these are not available as GPRs
>> If pointers are "special" in some way, a plain ADD may not be usable.
> <
> You might also have different overflow/saturation conditions with
> ADD.

OK.

I was thinking here mostly of things like capabilities and ISA's which
have different register widths or formats for integer and pointer types.

>>
>>
>> There are pros/cons, I am now leaning on the side of things that PC, LR,
>> SP, and GBR, are commonly referenced enough in other instructions that
>> it makes sense to have them available via the GPR encoding (assuming a
>> 32 or 64 register design).
> <
> IP is almost never used as an operand to other than memory reference
> instructions. Return address R0, SP R31are actual registers, So is FP R30,
> and Thread_Local_Data R16.

This is partly why I was thinking it might also make sense to alias it
with a Zero Register in most other contexts.

>>
>> A Zero register is also useful, but one trick here is to have a register
>> be interpreted as either PC or Zero depending on which register port it
>> is accessed from (any instruction which tries to use PC as an Index or
>> second argument will always get Zero).
>>
> In my opinion wasting a register to contain zero is simply a waste.
> So, I have STx #0,[Rbase+Rindex<<scale+Disp] and MOV Rd,#imm16
> when you really have to have it.

The main advantage of a Zero register would be that it makes it possible
to skip out on some encodings.

Say:
MOV Rm, Rn -> OR Rm, ZR, Rn
NEG Rm, Rn -> SUB ZR, Rm, Rn
...

Though, yes, in most other cases, it is kinda pointless.

>>
>> One can also debate the merits of instructions using PC and similar as a
>> target to encode branch instructions and similar.
>> BRA Disp -> ADD PC, Disp, PC //Special
>> BSR Disp -> ADD PC, Disp, LR //Special
>> RTS -> ADD LR, ZR, PC //Special
>> MOV Rm, Rn -> OR Rm, ZR, Rn //Pseudo
> <
> I recently added messages to My 66000 ISA. The caller sends a number of
> registers to the called (in accordance with ABI) and whether or not the
> called can access callers memory through indirection. Called runs in a
> different address space, with different privilege, under a potentially
> different Guest OS. Here Return Address = 0x01 (a magic cookie).
> <
> When called executes a RET instruction, control returns to caller in his
> own address space, at his privilege, in a core of his affinity,...
> <
> The called "subroutine" cannot tell that he was invoked by the message
> or called locally, except by looking at RA being the magic cookie. This
> works if safe stack is in use or not on both sides.
> <
> Indirection is my variant of PDP-11/70s MOV from and MOV to (alternate
> address space). I even set it up to use the ASID of the caller when accessing
> caller's memory via indirection.
> <
> Total number of instructions added: 2: Message Call, and Message Send.
> Total number of instructions modified: 2: RET and EXIT detect magic
> cookie.
> <

I was mostly thinking of, say, one wants to skip having dedicated
encoding space for things like BRA and BSR, and instead encodes them via
overloading ADD and similar, using special case logic for PC and LR and
similar.

Or, sort of like if one took the RISC-V route further and also left out
things like JAL and JALR and similar.

On Thursday, March 3, 2022 at 5:09:27 PM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Thursday, March 3, 2022 at 8:48:23 AM UTC-6, EricP wrote:
> >> Anton Ertl wrote:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>> As written elsethread, both ARM and IBM deprecated multiple store
> >>>> and load instructions - ARM by not including them in aarch64, IBM
> >>>> by restricting them in POWER to 32-bit size and to big-endian only.
> >>>> In other words, legacy code. POWER9 microcodes it, which incurs
> >>>> a significant penalty. Mitch explained that it is less a burden
> >>>> to his My 66000 implementations.
> >>>>
> >>>> aarch64 has load and store double instead.
> >>> ....
> >>>> Use in a function body is much harder (depending on what exactly
> >>>> is in the ISA). If you can load/store regiters up to the maximum
> >>>> register number that you have (POWER) or a register range (My
> >>>> 66000), you would have to work your whole register allocation
> >>>> around the load/store multiple instruction. This would be
> >>>> rather inconvenient, and I suspect that compilers would not use
> >>>> it.
> >>> I have certainly seen quite a few load-pair and store-pair
> >>> instructions in gcc-generated Aarch64 code outside function
> >>> prologue/epilogue:
> >>>
> >>> In the 6008 lines of output from "objdump -d
> >>> engine/engine-fast-ll-reg.o" (pretty much a single large function),
> >>> ldp occurs 133 times (among them 24 accesses through sp) and stp
> >>> occurs 76 times (17 accesses through sp). The accesses through sp are
> >>> probably around function calls, the others are other pairwise accesses
> >>> that the compiler could combine.
> >>>
> >>> So I expect that efficient load-multiple or store-multiple
> >>> instructions would also be used by gcc; the question is how often
> >>> there would be cases with more than two registers. Apparently not
> >>> enough to make the Aarch64 architects add instructions for that.
> >>>
> >>> The benefit of the load-pair and store-pair instructions over a pair
> >>> of loads/stores is that they reduce load/store-unit contention; of
> >>> course, the RISC-V answer to that is that the decoder can combine such
> >>> a pair into one pairwise micro-instruction.
> >> The register save set size sets the minimum width of a number of resources,
> >> the number of register read and write ports,
> >> width that LSQ should handle including store-load forwarding.
> >> With LDP/STP 2*64 it should not be a hardship even for a minimal
> >> implementation.
> >>
> >> For LDM/STM to run at full speed it would need to operate on a
> >> full 64B cache line, 8 register wide datapath to/from memory. That's
> >> - 8 read ports on the rename tables
> > <
> > A 6-wide machine already has 12-14 of these ports.
> Plus 8 rename write ports as it would need to rename 8 registers at once
> for each LDM uOp.
> > <
> >> - 8 read and 8 write register file ports
> > <
> > A 6-wide reservation station machine already has 12-14 of these
<
> It usually has lots of read ports but not that many write ports.
<
Consider the empty execution window, and you issue 6 instructions
into reservation stations. You need 12-14 ports into those stations
to write all the operands.
<
You only need 6 write ports to capture results.
<
When 6 instructions get issued, yo need read ports for all operands
12-14.
>
> Also maybe only a subset of the ports are available for load/store
> instructions. So issue logic can launch 6 or 8 uOps per clock
> but only 2 of them can be to the Load Store Unit.
<
A 6-wide machine should have 3 LD/ST stations, each accepting
3 operand (2 register 1 immediate), each capturing 6 results,
and when fired, you need read ports for all the operands 3×3=9.
> > <
> >> - 8 operand buses to LSQ, store-load forwarding,
> > <
> > A 6-wide machine already has 12-read 6-write.
<
> Again it may be that only a subset of buses run from RF to LSQ
> to avoid having a full blown operand crossbar to all FU.
<
You can so constrain your machine, I would not consider it, and
when I was told to by "higher ups" it ended up greatly complicating
the design, ultimately losing performance and schedule.
<
> > <
> >> (possibly also internally forwarding withing the LSQ itself)
> >> and input operand forwarding from FU results
> >> - 8 result buses from LSQ, with output forwarding
> > <
> > A 6-wide machine already has 6 of these.
> > <
> >> (plus possibly internal forwarding withing the LSQ itself)
> >> - 512 bit datapath to/from cache with alignment shifters for line straddles.
> > <
> > You are suggesting that these instructions occupy 1 instruction
> > in the stream, and are issued with another 5 instructions which
> > are completely dependent on the completion of the LDM or STM.
<
> Just exploring the hardware needed to optimize load or store multiple of
> up to 32 64-bit registers faster than 32 individual LD or ST instructions,
> ideally in 4 clocks. Similar concept to a hardware byte buffer block move..
>
> Cache line is 64B and we would like to pack 8 registers together
> in a single load or store operation. Decode sees an LDM/STM with a
> register mask or range select of up to 32 registers, and emits 1..4 uOps
> each for load or store of up to 8 data registers plus address registers.
>
> Each STM uOp basically takes over the Dispatcher resources,
> using all the read ports and buses to move the 0..2 address registers
> plus 1..8 data registers to a AGU-LSQ entry.
>
> Each LDM uOp Dispatch is like a regular load in that Dispatcher moves
> 0..2 address registers to a AGU-LSQ entry. But on completion it takes
> over all the result write and forwarding buses for its 1..8 results.
>
> Each set of 8 loaded or stored registers must obey all the usual rules
> for store-load forwarding and x86-TSO coherence. This is an expansion
> of existing rules since the memory bytes are contiguous though
> not necessarily cache aligned.
>
> If the load or store straddles 2 cache lines then it needs a 512-bit shifter
> and able to read/update 2 cache lines at once (dual port or odd/even banks).

On Thursday, March 3, 2022 at 6:17:24 PM UTC-6, BGB wrote:
> On 3/3/2022 1:45 PM, MitchAlsup wrote:
> > On Thursday, March 3, 2022 at 1:07:21 PM UTC-6, BGB wrote:
> >> On 3/3/2022 5:45 AM, a...@littlepinkcloud.invalid wrote:
> >>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
> >>>> On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
> >>>>> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> >>>>>>
> >>>>>> (32 bit ARM is interesting as it was designed to be nice to program
> >>>>>> in assembly, a consideration not normally part of instruction set
> >>>>>> design these days)
> >>>>>
> >>>>> That's an interesting point. In my experience 64-bit ARM is as nice to
> >>>>> program in assembly, at least as far as the set of base instructions
> >>>>> goes, even though there are more instructions.
> >>>>>
> >>>>> I also believe that if an instruction set is nice to program in
> >>>>> assembly, it's also nice to write a code generator for.
> >>>>
> >>>> Wasn't one of the results from the studies of generated code,that
> >>>> was used to justify RISC, that "nice to write assembly in" features
> >>>> such as complex and orthogonal addressing modes just weren't used in
> >>>> generated code?
> >>>
> >>> Are complex addressing modes nice to write assembly in, though? I've
> >>> never found it to be so. I think the problem identified with IBM 370
> >>> was that many of the addressing modes weren't being used by compilers
> >>> or by hand-cranked code, but I can't find any data for that one way or
> >>> the other.
> >>>
> >>> I can see the point of orthogonality, as long as it's not extended too
> >>> far. Of course no-one actually wants to have to use, say, a dedicated
> >>> pair of registers to do a multiply.
> >>>
> >> There is likely some room for debate here.
> >> Some people seemingly consider anything much beyond (Rb,Disp) to be
> >> complex...
> >>
> >>
> >> IME, ranking is roughly:
> >> (Rb,Disp):
> >> Very common
> >> (Rb,Ri):
> >> Also very common (2nd place)
> >> (Scale matches access size)
> >> (Rb,Ri*Sc, Disp)
> >> Uncommon, Harder to make use of.
> >>
> > My 66000 has scale encoded in one place and width encoded in another.
> > <
> > As to utility: although they only make up 2%-3% of instruction stream
> > they pretty much convert 2 instructions into 1 so they represent 2%-3%
> > performance gain. That may not be enough to make the cut in some
> > designs, and I disparage them not. On the other hand, while doing x86-64
> > I saw how little HW it took to do them, and how much it helped when
> > you really needed, and it saved a register when they were scant, too.
> > <
> Issue is that one needs to spare two extra bits to encode the separate
> scale.
<
I found a place for these--I stole bits used in calculation instructions
that negate operands.
>
> In my case, 32-bit encodings can only do:
> MOV.x (Rb, Ri), Rn
> Whereas Op64 and Op40x2 can do:
> MOV.x (Rb, Ri*Sc, Disp11) //Op64
> MOV.x (Rb, Ri*Sc, Disp5) //Op40x2
<
My equivalent does:
MEM Rd,[Rbase+Rindex<<scale+disp32]
>
> Though, this is considered part of an ISA extension.
> >>
> >>
> >> Then, "danger zone":
> >> @Rb+, @-Rb: Uncommon and requires an extra write port (1)
> >> @+Rb, @Rb-: Likewise
> >> @@Rb: Devil crap.
> >> ...
> > These require all sorts of compromise, including more register write
> > ports, more RAW dependencies, and are generally hard to pipeline.
> > In effect: you may not have shot yourself in the foot, but you took an
> > ice pick and drove it through nonetheless.
> This is part of why I left them out.
> >>
> >> 1: Though, in premise, these can map to C's "*ptr++" and "*--ptr" modes
> >> and similar, the occurrence of "*ptr++" in C isn't common enough to
> >> really justify having a dedicated instruction for it (when the increment
> >> or decrement can often be run in parallel with another instruction).
> >>
> >>
> >> While using PC or GBR or similar as a base register are useful, I will
> >> not consider them as separate address modes. Depending on the ISA asd
> >> ABI design, these may end up fairly common (namely for loading/storing
> >> global variables).
> >>
> >> Other semi-common cases are the ability to encode:
> >> LEA (Rb, Disp), Rn //More Common
> > <
> > This is often used as a prelude to MEM Rd,[Rn+Ri<<s] when you don't
> > have 2-registers+displacement memory references.
> > <
>
>
> >> LEA.x (Rb, Ri), Rn //Less Common
> > <
> > What does the ".x" signify ?
> That is the type used to encode the scale used for Ri.
> So:
> LEA.B (Rb, Ri), Rn // Rn=Rb+Ri
> LEA.W (Rb, Ri), Rn // Rn=Rb+Ri*2
> LEA.L (Rb, Ri), Rn // Rn=Rb+Ri*4
> LEA.Q (Rb, Ri), Rn // Rn=Rb+Ri*8
<
Can I ask if you were a bit peeved at Thomas' dislike of "dots" ?
>
> This detail can be glossed over for the (Rb, Disp) case.
>
> In my case, for XLEA, only the .B encoding was provided in the base ISA,
> and the others were provided indirectly via Op64 encodings.
>
> Partly this was because some other encodings occupied the same space
> that might have otherwise been used for the other LEA's (and scaled
> index LEA being fairly uncommon).
> >>
> >> This can almost be subsumed into ADD, except:
> >> It is useful to be able to encode PC or GBR or similar as a base
> >> If these are not available as GPRs
> >> If pointers are "special" in some way, a plain ADD may not be usable.
> > <
> > You might also have different overflow/saturation conditions with
> > ADD.
> OK.
>
> I was thinking here mostly of things like capabilities and ISA's which
> have different register widths or formats for integer and pointer types.
> >>
> >>
> >> There are pros/cons, I am now leaning on the side of things that PC, LR,
> >> SP, and GBR, are commonly referenced enough in other instructions that
> >> it makes sense to have them available via the GPR encoding (assuming a
> >> 32 or 64 register design).
> > <
> > IP is almost never used as an operand to other than memory reference
> > instructions. Return address R0, SP R31are actual registers, So is FP R30,
> > and Thread_Local_Data R16.
> This is partly why I was thinking it might also make sense to alias it
> with a Zero Register in most other contexts.
> >>
> >> A Zero register is also useful, but one trick here is to have a register
> >> be interpreted as either PC or Zero depending on which register port it
> >> is accessed from (any instruction which tries to use PC as an Index or
> >> second argument will always get Zero).
> >>
> > In my opinion wasting a register to contain zero is simply a waste.
> > So, I have STx #0,[Rbase+Rindex<<scale+Disp] and MOV Rd,#imm16
> > when you really have to have it.
> The main advantage of a Zero register would be that it makes it possible
> to skip out on some encodings.
>
> Say:
> MOV Rm, Rn -> OR Rm, ZR, Rn
> NEG Rm, Rn -> SUB ZR, Rm, Rn
<
I have not seen a NEG yet, since Brian got his LLVM port up.
<
That is:
CALK Rd,-R1,-R2
<
gets rid of almost all of the 1-operands. The kind of negation is
dependent on the kind of calculation {integer is 2-s complement,
logical is bit-inversion, FP is sign inversion.}
<
> ...
>
> Though, yes, in most other cases, it is kinda pointless.
> >>
> >> One can also debate the merits of instructions using PC and similar as a
> >> target to encode branch instructions and similar.
> >> BRA Disp -> ADD PC, Disp, PC //Special
> >> BSR Disp -> ADD PC, Disp, LR //Special
> >> RTS -> ADD LR, ZR, PC //Special
> >> MOV Rm, Rn -> OR Rm, ZR, Rn //Pseudo
> > <
> > I recently added messages to My 66000 ISA. The caller sends a number of
> > registers to the called (in accordance with ABI) and whether or not the
> > called can access callers memory through indirection. Called runs in a
> > different address space, with different privilege, under a potentially
> > different Guest OS. Here Return Address = 0x01 (a magic cookie).
> > <
> > When called executes a RET instruction, control returns to caller in his
> > own address space, at his privilege, in a core of his affinity,...
> > <
> > The called "subroutine" cannot tell that he was invoked by the message
> > or called locally, except by looking at RA being the magic cookie. This
> > works if safe stack is in use or not on both sides.
> > <
> > Indirection is my variant of PDP-11/70s MOV from and MOV to (alternate
> > address space). I even set it up to use the ASID of the caller when accessing
> > caller's memory via indirection.
> > <
> > Total number of instructions added: 2: Message Call, and Message Send.
> > Total number of instructions modified: 2: RET and EXIT detect magic
> > cookie.
> > <
> I was mostly thinking of, say, one wants to skip having dedicated
> encoding space for things like BRA and BSR, and instead encodes them via
> overloading ADD and similar, using special case logic for PC and LR and
> similar.
<
How do you prevent things like::
<
DIV IP,R7,R19
<
But then again, maybe YOU don't want to.
>
> Or, sort of like if one took the RISC-V route further and also left out
> things like JAL and JALR and similar.
<
Realistically, my JMP instructions are equivalent to:: MOV IP,Reg
>
> Though, this would severely limit direct branch displacements, likely
> requiring a fair number of cases to use indirect branching instead.
>
I should note: I have switches and method calls that do not require
jumps.....and ARE position independent.
>
>
> Granted, from a cost POV, invoking magic when certain registers are used
> in an encoding doesn't really save anything over having a dedicated
> encoding (and, behaviorally, a BRA or BSR is very different from an ADD;
> these funky edge cases would likely still need to be detected and
> handled by the instruction decoder).
>
> But, this thing could still have "appeal" to the "More RISC means
> smaller instruction listing" crowd.
>
>
> Eg:
> 0Xddssdd //LD/ST (Disp only, for peak RISC)
> 1Xddsstt //ALU
> 20=ADD, 21=SUB, 22=SHLD, 23=SHAD,
> 24=-, 25=AND, 26=OR, 27=XOR, ...
> 28=ADDI, 29=SUBI, 2A=SHLDI, 2B=SHADI,
> 2C=-, 2D=ANDI, 2E=ORI, 2F=XORI, ...
>
> Then skip out on all these "frivolous" features like, branch or constant
> load instructions (eg, "Why do you need larger constants when you can do
> a PC relative load?...").
<
You pollute the Data cache by running instruction stream stuff through it.
>
> Exercise for reader being how one would implement conditional branching
> with neither conditional branch nor compare-and-branch instructions.
>
> ...
>
>
> >> ...
> >>
> >> ...
> >>
> >>
> >>> Andrew.

According to Ivan Godard <ivan@millcomputing.com>:
>> Restricting the user to single-letter variables would not be such
>> a great idea, I think.
>
>Was highly successful in the original BASIC.

Uh, sort of. You could have letter-digit, too. The compiler was
stupendously fast for the sort of small student programs that
Dartmouth's system usually ran so the tiny name space was excusable.

If you wanted to write real programs, they had Fortran and eventually PL/I.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said:
>Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>Wasn't one of the results from the studies of generated code,that was
>>used to justify RISC, that "nice to write assembly in" features such as
>>complex and orthogonal addressing modes just weren't used in generated code?
>
>There are multiple aspects to this:
>
>* Compilers around 1980 may have had a hard time generating some of
> these addressing modes, and that's why they did not generate them.

The Berkley RISC project used the old Unix pcc compiler which had an adequate
but not great code generator. They invented register windows because it
didn't try to minimize register usage. At the same time the IBM 801 had
a really good compiler with graph coloring so it knew exactly which registers
were live when, and it had a regular register file (24 bits as I recall)
and just single loads and stores.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 3/3/2022 6:29 PM, MitchAlsup wrote:
> On Thursday, March 3, 2022 at 6:17:24 PM UTC-6, BGB wrote:
>> On 3/3/2022 1:45 PM, MitchAlsup wrote:
>>> On Thursday, March 3, 2022 at 1:07:21 PM UTC-6, BGB wrote:
>>>> On 3/3/2022 5:45 AM, a...@littlepinkcloud.invalid wrote:
>>>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
>>>>>> On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
>>>>>>> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>>>>>>>>
>>>>>>>> (32 bit ARM is interesting as it was designed to be nice to program
>>>>>>>> in assembly, a consideration not normally part of instruction set
>>>>>>>> design these days)
>>>>>>>
>>>>>>> That's an interesting point. In my experience 64-bit ARM is as nice to
>>>>>>> program in assembly, at least as far as the set of base instructions
>>>>>>> goes, even though there are more instructions.
>>>>>>>
>>>>>>> I also believe that if an instruction set is nice to program in
>>>>>>> assembly, it's also nice to write a code generator for.
>>>>>>
>>>>>> Wasn't one of the results from the studies of generated code,that
>>>>>> was used to justify RISC, that "nice to write assembly in" features
>>>>>> such as complex and orthogonal addressing modes just weren't used in
>>>>>> generated code?
>>>>>
>>>>> Are complex addressing modes nice to write assembly in, though? I've
>>>>> never found it to be so. I think the problem identified with IBM 370
>>>>> was that many of the addressing modes weren't being used by compilers
>>>>> or by hand-cranked code, but I can't find any data for that one way or
>>>>> the other.
>>>>>
>>>>> I can see the point of orthogonality, as long as it's not extended too
>>>>> far. Of course no-one actually wants to have to use, say, a dedicated
>>>>> pair of registers to do a multiply.
>>>>>
>>>> There is likely some room for debate here.
>>>> Some people seemingly consider anything much beyond (Rb,Disp) to be
>>>> complex...
>>>>
>>>>
>>>> IME, ranking is roughly:
>>>> (Rb,Disp):
>>>> Very common
>>>> (Rb,Ri):
>>>> Also very common (2nd place)
>>>> (Scale matches access size)
>>>> (Rb,Ri*Sc, Disp)
>>>> Uncommon, Harder to make use of.
>>>>
>>> My 66000 has scale encoded in one place and width encoded in another.
>>> <
>>> As to utility: although they only make up 2%-3% of instruction stream
>>> they pretty much convert 2 instructions into 1 so they represent 2%-3%
>>> performance gain. That may not be enough to make the cut in some
>>> designs, and I disparage them not. On the other hand, while doing x86-64
>>> I saw how little HW it took to do them, and how much it helped when
>>> you really needed, and it saved a register when they were scant, too.
>>> <
>> Issue is that one needs to spare two extra bits to encode the separate
>> scale.
> <
> I found a place for these--I stole bits used in calculation instructions
> that negate operands.
>>
>> In my case, 32-bit encodings can only do:
>> MOV.x (Rb, Ri), Rn
>> Whereas Op64 and Op40x2 can do:
>> MOV.x (Rb, Ri*Sc, Disp11) //Op64
>> MOV.x (Rb, Ri*Sc, Disp5) //Op40x2
> <
> My equivalent does:
> MEM Rd,[Rbase+Rindex<<scale+disp32]

OK.

There is not a direct equivalent in BJX2, where the options are:
(Rb, Disp33s) //Jumbo
(Rb, Ri, Disp13s) // Op64
(Rb, Ri*Sc, Disp11s) //Op64

There is not a dedicated Ri*Sc encoding with no Disp field, the closest
equivalent being to encode it with Disp==0.

>>
>> Though, this is considered part of an ISA extension.
>>>>
>>>>
>>>> Then, "danger zone":
>>>> @Rb+, @-Rb: Uncommon and requires an extra write port (1)
>>>> @+Rb, @Rb-: Likewise
>>>> @@Rb: Devil crap.
>>>> ...
>>> These require all sorts of compromise, including more register write
>>> ports, more RAW dependencies, and are generally hard to pipeline.
>>> In effect: you may not have shot yourself in the foot, but you took an
>>> ice pick and drove it through nonetheless.
>> This is part of why I left them out.
>>>>
>>>> 1: Though, in premise, these can map to C's "*ptr++" and "*--ptr" modes
>>>> and similar, the occurrence of "*ptr++" in C isn't common enough to
>>>> really justify having a dedicated instruction for it (when the increment
>>>> or decrement can often be run in parallel with another instruction).
>>>>
>>>>
>>>> While using PC or GBR or similar as a base register are useful, I will
>>>> not consider them as separate address modes. Depending on the ISA asd
>>>> ABI design, these may end up fairly common (namely for loading/storing
>>>> global variables).
>>>>
>>>> Other semi-common cases are the ability to encode:
>>>> LEA (Rb, Disp), Rn //More Common
>>> <
>>> This is often used as a prelude to MEM Rd,[Rn+Ri<<s] when you don't
>>> have 2-registers+displacement memory references.
>>> <
>>
>>
>>>> LEA.x (Rb, Ri), Rn //Less Common
>>> <
>>> What does the ".x" signify ?
>> That is the type used to encode the scale used for Ri.
>> So:
>> LEA.B (Rb, Ri), Rn // Rn=Rb+Ri
>> LEA.W (Rb, Ri), Rn // Rn=Rb+Ri*2
>> LEA.L (Rb, Ri), Rn // Rn=Rb+Ri*4
>> LEA.Q (Rb, Ri), Rn // Rn=Rb+Ri*8
> <
> Can I ask if you were a bit peeved at Thomas' dislike of "dots" ?

I have them because they were inherited from GAS and SuperH.

But, dots aren't too bad, '/' and '+' and similar in opcode names are
worse...

One could argue that I had '?', but it isn't really part of the
instruction name per-se, so it doesn't count.

>>
>> This detail can be glossed over for the (Rb, Disp) case.
>>
>> In my case, for XLEA, only the .B encoding was provided in the base ISA,
>> and the others were provided indirectly via Op64 encodings.
>>
>> Partly this was because some other encodings occupied the same space
>> that might have otherwise been used for the other LEA's (and scaled
>> index LEA being fairly uncommon).
>>>>
>>>> This can almost be subsumed into ADD, except:
>>>> It is useful to be able to encode PC or GBR or similar as a base
>>>> If these are not available as GPRs
>>>> If pointers are "special" in some way, a plain ADD may not be usable.
>>> <
>>> You might also have different overflow/saturation conditions with
>>> ADD.
>> OK.
>>
>> I was thinking here mostly of things like capabilities and ISA's which
>> have different register widths or formats for integer and pointer types.
>>>>
>>>>
>>>> There are pros/cons, I am now leaning on the side of things that PC, LR,
>>>> SP, and GBR, are commonly referenced enough in other instructions that
>>>> it makes sense to have them available via the GPR encoding (assuming a
>>>> 32 or 64 register design).
>>> <
>>> IP is almost never used as an operand to other than memory reference
>>> instructions. Return address R0, SP R31are actual registers, So is FP R30,
>>> and Thread_Local_Data R16.
>> This is partly why I was thinking it might also make sense to alias it
>> with a Zero Register in most other contexts.
>>>>
>>>> A Zero register is also useful, but one trick here is to have a register
>>>> be interpreted as either PC or Zero depending on which register port it
>>>> is accessed from (any instruction which tries to use PC as an Index or
>>>> second argument will always get Zero).
>>>>
>>> In my opinion wasting a register to contain zero is simply a waste.
>>> So, I have STx #0,[Rbase+Rindex<<scale+Disp] and MOV Rd,#imm16
>>> when you really have to have it.
>> The main advantage of a Zero register would be that it makes it possible
>> to skip out on some encodings.
>>
>> Say:
>> MOV Rm, Rn -> OR Rm, ZR, Rn
>> NEG Rm, Rn -> SUB ZR, Rm, Rn
> <
> I have not seen a NEG yet, since Brian got his LLVM port up.
> <
> That is:
> CALK Rd,-R1,-R2
> <
> gets rid of almost all of the 1-operands. The kind of negation is
> dependent on the kind of calculation {integer is 2-s complement,
> logical is bit-inversion, FP is sign inversion.}
> <

On Thursday, March 3, 2022 at 8:22:28 PM UTC-6, BGB wrote:
> On 3/3/2022 6:29 PM, MitchAlsup wrote:
>
> If one were trying to "distill things down to the essence of RISC" (in a
> possibly misguided way), may as well also leave out things like MUL and
> DIV and similar.
<
Inarguably 432 went too far, arguably VAX went too far in the CISC
directions.
<
I have been arguing that many RISCs went too far in the RISC direction,
too.
<
In particular, My 66000 has 32-bit and 64-bit constants for anything
needed (can't be done at compile time). In the case of STs, which
have both 32 and 64 bit displacements, but also 32 and 64-bit
immediates (as well as 5-bit immediates). This left me with inst-
ructons as long as 5-words (360 sized words not x86 sized words).
<
Surprisingly, this increases code density ! That is correct, making
instructions longer in the right ways makes the code footprint
smaller !
<
> >>
> >> Or, sort of like if one took the RISC-V route further and also left out
> >> things like JAL and JALR and similar.
> > <
> > Realistically, my JMP instructions are equivalent to:: MOV IP,Reg
> This isn't too far off from my case either within the pipeline.
> >>
> >> Though, this would severely limit direct branch displacements, likely
> >> requiring a fair number of cases to use indirect branching instead.
> >>
> > I should note: I have switches and method calls that do not require
> > jumps.....and ARE position independent.
> They are position-independent in BJX2 as well...
> >>
> >>
<snip>
> > <
> > You pollute the Data cache by running instruction stream stuff through it.
> Yes, granted, but more traditional RISCs did do it this way, and it IS a
> way to make the ISA listing smaller...
>
> This idea was partly intended as a joke, like taking a particular
> interpretation of the RISC philosophy "possibly a little too far".
>
I was there in early 1980s, I saw the malformed architectures, I saw
the limitations of the arguments, and I had to keep quiet and get my
stuff done.
<
More recently, I have not been under time pressure of "schedule" and
have produced much better art of architecture than what can be done
when a schedule indicates "this must be done by then".
<
It is like making Boef Bourguignon in 30 minutes.
>
> Then again, apart from needing some way to pull of conditional jumps in
> a "sane" way, this isn't likely to be "that" unworkable (performance and
> code density not withstanding).
>
> Could probably include a T-bit and predication.
> SUB R8, R9, ZR //Interpreted as "CMPGT R8, R9", Updates T
> ADD?T PC, 120, PC
>
> Likewise:
> AND R8, R9, ZR //Interpreted as TEST

On 2022-03-04 4:15, John Levine wrote:
> According to Ivan Godard <ivan@millcomputing.com>:
>>> Restricting the user to single-letter variables would not be such
>>> a great idea, I think.
>>
>> Was highly successful in the original BASIC.
>
> Uh, sort of. You could have letter-digit, too. The compiler was
> stupendously fast for the sort of small student programs that
> Dartmouth's system usually ran so the tiny name space was excusable.
>
> If you wanted to write real programs, they had Fortran and eventually PL/I.

In a former occupation, a boss of mine had written a program in HP BASIC
to control a radio telescope with an HP-2100 mini (yes, magnetic core
memory, 32 KB).

The program was getting rather large (using up lots and lots of punched
paper tape). He had an A4 sheet of paper ruled into boxes, with A-Z on
the vertical axis and 0-9 on the horizontal. Whenever he needed a new
variable name he looked for an empty box, defined the variable, and
ticked the box.

When all boxes were ticked he started using arrays, with a specific role
for each element.

And of course comments in the source code consumed run-time memory
space, so there were not many of those...

I introduced HP Algol and we were happier. Programs ran faster, too. And
were easily made multi-threaded with a little bit of assembler.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Thursday, March 3, 2022 at 6:17:24 PM UTC-6, BGB wrote:

>> Say:
>> MOV Rm, Rn -> OR Rm, ZR, Rn
>> NEG Rm, Rn -> SUB ZR, Rm, Rn
><
> I have not seen a NEG yet, since Brian got his LLVM port up.

I can show you some :-)

they are not frequent, but they exist. This is for the Polyhedron
benchmark fatigue2.f90, with the latest version of the compiler.

$ grep "add.*#0,-" fatigue2.s
fadd r3,#0,-r13
fadd r1,#0,-r1
fadd r4,#0,-r1
fadd r28,#0,-r28
fadd r28,#0,-r27
fadd r10,#0,-r10
fadd r6,#0,-r6
fadd r6,#0,-r6
fadd r7,#0,-r7
fadd r6,#0,-r6
fadd r7,#0,-r7
fadd r6,#0,-r6
fadd r13,#0,-r13
fadd r11,#0,-r11
fadd r6,#0,-r6
add r7,#0,-r7
add r10,#0,-r9
add r2,#0,-r14
fadd r4,#0,-r4
fadd r2,#0,-r2

$ wc -l fatigue2.s
15727 fatigue2.s

A typical example for the floating point stuff is

fmul r7,r7,r4
fmul r6,r6,r4
fadd r6,#0,-r6
fmac r6,r14,r13,r6
fadd r7,#0,-r7
fmac r7,r14,r9,r7
fmul r7,r7,r15
fmul r6,r6,r15

and the example for r7 is followed by

add r7,#0,-r7
..LBB14_47: ; %vector.body282.epil
; =>This Inner Loop Header: Depth=1
sll r8,r6,<0:3>
.loc 1 1392 1 ; fatigue2.f90:1392:1
or r8,r8,#8
std r5,[r8,r2,0]
std r5,[r8,r2,-8]
std r5,[r8,r2,16]
std r5,[r8,r2,8]
add r6,r6,#4
add r8,r7,#1
cmp r7,r8,r7
srl r7,r7,<1:12>
cmp r9,r7,#1
mov r7,r8
bne r9,.LBB14_47

On 3/3/2022 8:50 PM, MitchAlsup wrote:
> On Thursday, March 3, 2022 at 8:22:28 PM UTC-6, BGB wrote:
>> On 3/3/2022 6:29 PM, MitchAlsup wrote:
>>
>> If one were trying to "distill things down to the essence of RISC" (in a
>> possibly misguided way), may as well also leave out things like MUL and
>> DIV and similar.
> <
> Inarguably 432 went too far, arguably VAX went too far in the CISC
> directions.

What little I looked at iAPX 432, it was a bit WTF.

> <
> I have been arguing that many RISCs went too far in the RISC direction,
> too.

Possibly true.
The first wave has mostly died off now.

I never saw the first wave of RISCs firsthand.

Pretty much my whole life has been in the era of x86-based desktop PCs
and similar.

Have seen some amount of complaining about stuff "not being RISC
enough", which often amounts to them wanting the ISA listing to be
fairly small.

So, the joke ISA was partly a case of "what if one tried to design an
ISA like how people complaining about things not being RISCy enough seem
to want it". This was sort of the direction I tried to go with the idea.

Most traditional RISCs I am aware of, do have dedicated branch
instructions and similar though, but omitting them could be a way to
make the listing smaller, which does seem to be a major indicator of
"RISCness" in many peoples' minds, ...

Making an "actually good" ISA would note really be the priority of such
a design though (hence the lack of indexed load/store, and suggestion of
loading constants from memory, both of which are "RISC" things, but not
necessarily "good idea" things...).

> <
> In particular, My 66000 has 32-bit and 64-bit constants for anything
> needed (can't be done at compile time). In the case of STs, which
> have both 32 and 64 bit displacements, but also 32 and 64-bit
> immediates (as well as 5-bit immediates). This left me with inst-
> ructons as long as 5-words (360 sized words not x86 sized words).
> <
> Surprisingly, this increases code density ! That is correct, making
> instructions longer in the right ways makes the code footprint
> smaller !
> <

Yeah. There are possible advantages to a consistent encoding, rather
than an ad-hoc collection of encodings.

But, alas...

>>>>
>>>> Or, sort of like if one took the RISC-V route further and also left out
>>>> things like JAL and JALR and similar.
>>> <
>>> Realistically, my JMP instructions are equivalent to:: MOV IP,Reg
>> This isn't too far off from my case either within the pipeline.
>>>>
>>>> Though, this would severely limit direct branch displacements, likely
>>>> requiring a fair number of cases to use indirect branching instead.
>>>>
>>> I should note: I have switches and method calls that do not require
>>> jumps.....and ARE position independent.
>> They are position-independent in BJX2 as well...
>>>>
>>>>
> <snip>
>>> <
>>> You pollute the Data cache by running instruction stream stuff through it.
>> Yes, granted, but more traditional RISCs did do it this way, and it IS a
>> way to make the ISA listing smaller...
>>
>> This idea was partly intended as a joke, like taking a particular
>> interpretation of the RISC philosophy "possibly a little too far".
>>
> I was there in early 1980s, I saw the malformed architectures, I saw
> the limitations of the arguments, and I had to keep quiet and get my
> stuff done.
> <
> More recently, I have not been under time pressure of "schedule" and
> have produced much better art of architecture than what can be done
> when a schedule indicates "this must be done by then".
> <
> It is like making Boef Bourguignon in 30 minutes.

In my case, I ended up where I ended up via incremental fiddly.
Could maybe be better, but not come up with much of anything "clearly
better" than what I have already (even as much as what I have already
kinda sucks in some ways).

>>
>> Then again, apart from needing some way to pull of conditional jumps in
>> a "sane" way, this isn't likely to be "that" unworkable (performance and
>> code density not withstanding).
>>
>> Could probably include a T-bit and predication.
>> SUB R8, R9, ZR //Interpreted as "CMPGT R8, R9", Updates T
>> ADD?T PC, 120, PC
>>
>> Likewise:
>> AND R8, R9, ZR //Interpreted as TEST
>

I went and wrote a quick and dirty spec for the idea at least (doubtful
I will do much with it beyond this).

This was amid getting around to implementing S3M playback support for my
MOD player code.

After dealing with some of this, I start to suspect some of this stuff
could probably be done "better" with a format partway between a Tracker
format and MIDI. But, this partly falls more into "meh, whatever"
territory (I have neither the musical skills nor motivation to make
effective use of such a thing).

BGB <cr88192@gmail.com> schrieb:
> On 3/3/2022 8:50 PM, MitchAlsup wrote:
>> On Thursday, March 3, 2022 at 8:22:28 PM UTC-6, BGB wrote:
>>> On 3/3/2022 6:29 PM, MitchAlsup wrote:
>>>
>>> If one were trying to "distill things down to the essence of RISC" (in a
>>> possibly misguided way), may as well also leave out things like MUL and
>>> DIV and similar.
>> <
>> Inarguably 432 went too far, arguably VAX went too far in the CISC
>> directions.
>
> What little I looked at iAPX 432, it was a bit WTF.
>
>
>> <
>> I have been arguing that many RISCs went too far in the RISC direction,
>> too.
>
> Possibly true.
> The first wave has mostly died off now.
>
> I never saw the first wave of RISCs firsthand.

I worked a lot on HP-PA workstations. After IBM mainframes using
3270-compatible terminals, using a variety of HP 9000/700 series
machines. HP-UX wasn't great, but it served, and because they
had been purchased as CAD workstations, their screens were _huge_.
Processors were HP-PA, at least in later days.

I also worked on SGI-Machines using terminals, MIPS-based, and
a bit on IBM RS/6000 systems (on one occasion only, compiling
code on them for the Distributed Internet Crack of a 40-bit
DES code - anybody else remember that one? Terje, this sounds
like somthing that would have appealed to you.)

MitchAlsup <MitchAlsup@aol.com> wrote:
> Brian

which one?

> had little trouble using:
> MEM Rd,[Rbase+Rindex<<size+Displacement]
> as the model.

That form turns out to be very useful on x86 for running Java, where
an array has a descriptor at its start, followed by the data. That was
one of the very few times I can think of where I've missed an x86 CISC
feature. In practice though, when running on ARM the offset adjustment
can be lifted out of loops, so it doesn't seem much to matter.

> With the additions of:
> Rbase = R0 substitutes IP as base register
> Rindex = R0 substituted 0x0 as the index

Yeah, I think I see.

Andrew.

On Friday, March 4, 2022 at 1:25:08 AM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Thursday, March 3, 2022 at 6:17:24 PM UTC-6, BGB wrote:
>
> >> Say:
> >> MOV Rm, Rn -> OR Rm, ZR, Rn
> >> NEG Rm, Rn -> SUB ZR, Rm, Rn
> ><
> > I have not seen a NEG yet, since Brian got his LLVM port up.
> I can show you some :-)
>
> they are not frequent, but they exist. This is for the Polyhedron
> benchmark fatigue2.f90, with the latest version of the compiler.
>
> $ grep "add.*#0,-" fatigue2.s
> fadd r3,#0,-r13
> fadd r1,#0,-r1
> fadd r4,#0,-r1
> fadd r28,#0,-r28
> fadd r28,#0,-r27
> fadd r10,#0,-r10
> fadd r6,#0,-r6
> fadd r6,#0,-r6
> fadd r7,#0,-r7
> fadd r6,#0,-r6
> fadd r7,#0,-r7
> fadd r6,#0,-r6
> fadd r13,#0,-r13
> fadd r11,#0,-r11
> fadd r6,#0,-r6
> add r7,#0,-r7
> add r10,#0,-r9
> add r2,#0,-r14
> fadd r4,#0,-r4
> fadd r2,#0,-r2
>
> $ wc -l fatigue2.s
> 15727 fatigue2.s
>
> A typical example for the floating point stuff is
>
> fmul r7,r7,r4
> fmul r6,r6,r4
> fadd r6,#0,-r6
> fmac r6,r14,r13,r6
<
Above and below looks like a missed optimization, as
FMAC Rd,Rm,Rp,-Ra is available.
<
> fadd r7,#0,-r7
> fmac r7,r14,r9,r7
> fmul r7,r7,r15
> fmul r6,r6,r15
>
> and the example for r7 is followed by
>
> add r7,#0,-r7
> .LBB14_47: ; %vector.body282.epil
> ; =>This Inner Loop Header: Depth=1
> sll r8,r6,<0:3>
> .loc 1 1392 1 ; fatigue2.f90:1392:1
> or r8,r8,#8
> std r5,[r8,r2,0]
> std r5,[r8,r2,-8]
> std r5,[r8,r2,16]
> std r5,[r8,r2,8]
> add r6,r6,#4
> add r8,r7,#1
> cmp r7,r8,r7
> srl r7,r7,<1:12>
> cmp r9,r7,#1
> mov r7,r8
> bne r9,.LBB14_47

On Friday, March 4, 2022 at 3:44:44 AM UTC-6, BGB wrote:
> On 3/3/2022 8:50 PM, MitchAlsup wrote:
> > On Thursday, March 3, 2022 at 8:22:28 PM UTC-6, BGB wrote:
> >> On 3/3/2022 6:29 PM, MitchAlsup wrote:
> >>
> >> If one were trying to "distill things down to the essence of RISC" (in a
> >> possibly misguided way), may as well also leave out things like MUL and
> >> DIV and similar.
> > <
> > Inarguably 432 went too far, arguably VAX went too far in the CISC
> > directions.
> What little I looked at iAPX 432, it was a bit WTF.
> > <
> > I have been arguing that many RISCs went too far in the RISC direction,
> > too.
> Possibly true.
> The first wave has mostly died off now.
>
> I never saw the first wave of RISCs firsthand.
<
I was in the prime of life................alas
>
> Pretty much my whole life has been in the era of x86-based desktop PCs
> and similar.
>
>
> Have seen some amount of complaining about stuff "not being RISC
> enough", which often amounts to them wanting the ISA listing to be
> fairly small.
>
> So, the joke ISA was partly a case of "what if one tried to design an
> ISA like how people complaining about things not being RISCy enough seem
> to want it". This was sort of the direction I tried to go with the idea.
>
>
> Most traditional RISCs I am aware of, do have dedicated branch
> instructions and similar though, but omitting them could be a way to
> make the listing smaller, which does seem to be a major indicator of
> "RISCness" in many peoples' minds, ...
>
> Making an "actually good" ISA would note really be the priority of such
> a design though (hence the lack of indexed load/store, and suggestion of
> loading constants from memory, both of which are "RISC" things, but not
> necessarily "good idea" things...).
<
I started My 66000 in April of 2006 and have been making incremental
improvements ever since.
> > <
> > In particular, My 66000 has 32-bit and 64-bit constants for anything
> > needed (can't be done at compile time). In the case of STs, which
> > have both 32 and 64 bit displacements, but also 32 and 64-bit
> > immediates (as well as 5-bit immediates). This left me with inst-
> > ructons as long as 5-words (360 sized words not x86 sized words).
> > <
> > Surprisingly, this increases code density ! That is correct, making
> > instructions longer in the right ways makes the code footprint
> > smaller !
> > <
> Yeah. There are possible advantages to a consistent encoding, rather
> than an ad-hoc collection of encodings.
>
> But, alas...
> >>>>
> >>>> Or, sort of like if one took the RISC-V route further and also left out
> >>>> things like JAL and JALR and similar.
> >>> <
> >>> Realistically, my JMP instructions are equivalent to:: MOV IP,Reg
> >> This isn't too far off from my case either within the pipeline.
> >>>>
> >>>> Though, this would severely limit direct branch displacements, likely
> >>>> requiring a fair number of cases to use indirect branching instead.
> >>>>
> >>> I should note: I have switches and method calls that do not require
> >>> jumps.....and ARE position independent.
> >> They are position-independent in BJX2 as well...
> >>>>
> >>>>
> > <snip>
> >>> <
> >>> You pollute the Data cache by running instruction stream stuff through it.
> >> Yes, granted, but more traditional RISCs did do it this way, and it IS a
> >> way to make the ISA listing smaller...
> >>
> >> This idea was partly intended as a joke, like taking a particular
> >> interpretation of the RISC philosophy "possibly a little too far".
> >>
> > I was there in early 1980s, I saw the malformed architectures, I saw
> > the limitations of the arguments, and I had to keep quiet and get my
> > stuff done.
> > <
> > More recently, I have not been under time pressure of "schedule" and
> > have produced much better art of architecture than what can be done
> > when a schedule indicates "this must be done by then".
> > <
> > It is like making Boef Bourguignon in 30 minutes.
<
> In my case, I ended up where I ended up via incremental fiddly.
<
The word "mung" comes to mind.......
<
> Could maybe be better, but not come up with much of anything "clearly
> better" than what I have already (even as much as what I have already
> kinda sucks in some ways).
> >>
> >> Then again, apart from needing some way to pull of conditional jumps in
> >> a "sane" way, this isn't likely to be "that" unworkable (performance and
> >> code density not withstanding).
> >>
> >> Could probably include a T-bit and predication.
> >> SUB R8, R9, ZR //Interpreted as "CMPGT R8, R9", Updates T
> >> ADD?T PC, 120, PC
> >>
> >> Likewise:
> >> AND R8, R9, ZR //Interpreted as TEST
> >
> I went and wrote a quick and dirty spec for the idea at least (doubtful
> I will do much with it beyond this).
>
>
> This was amid getting around to implementing S3M playback support for my
> MOD player code.
>
>
> After dealing with some of this, I start to suspect some of this stuff
> could probably be done "better" with a format partway between a Tracker
> format and MIDI. But, this partly falls more into "meh, whatever"
> territory (I have neither the musical skills nor motivation to make
> effective use of such a thing).

John Levine <johnl@taugh.com> writes:
> The Berkley RISC project used the old Unix pcc compiler which had an adequate
> but not great code generator.

The coder had to use "register" declarations to do the register allocation
(manually). If you picked the right number of such, and if your code
generation target templates for that CPU lined up, you could get tolerable
code. (I remember code bases with "reg1", "reg2", etc. modifiers so you
could ifdef to fit against a given target's register resources.)

The whole design of pcc's code generation was hostile to the code generator
deciding any of these tradeoffs. I suspect that's why this generation of
compiler technology has faded away without a trace.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

According to Andy Valencia <vandys@vsta.org>:
>John Levine <johnl@taugh.com> writes:
>> The Berkley RISC project used the old Unix pcc compiler which had an adequate
>> but not great code generator. ...

>The whole design of pcc's code generation was hostile to the code generator
>deciding any of these tradeoffs. I suspect that's why this generation of
>compiler technology has faded away without a trace.

In its defense, pcc did what it was designed to do. It generated decent code
for C programs on a wide range of targets, and it was small enough to fit on
a PDP-11 where you got 64K of code and 64K of data.

On modern computers where you can always keep the internal form of an entire program
in RAM, you can do a lot better.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, March 4, 2022 at 9:29:31 AM UTC-6, Andy Valencia wrote:
> John Levine <jo...@taugh.com> writes:
> > The Berkley RISC project used the old Unix pcc compiler which had an adequate
> > but not great code generator.
> The coder had to use "register" declarations to do the register allocation
> (manually). If you picked the right number of such, and if your code
> generation target templates for that CPU lined up, you could get tolerable
> code. (I remember code bases with "reg1", "reg2", etc. modifiers so you
> could ifdef to fit against a given target's register resources.)
<
When I did the Denelcor HEP port of this compiler, I rewrote the entire backend;
throwing away the "take a guess and try again" code generation philosophy;
and creating a code generator that generated perfect straight line code--but
having to forget everything at labels. The code generated by my back end ran
2× as fast as the native port.
>
> The whole design of pcc's code generation was hostile to the code generator
> deciding any of these tradeoffs. I suspect that's why this generation of
> compiler technology has faded away without a trace.
<
The seminal paper of this kind of compiler code generator was "maximal
munching method"--which by a careless oversight '<' was replaced by '>'
ran as the "minimal munching method"--CMU circa 1975 for VAX-like ISAs.
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html