On 3/11/2025 1:56 PM, MitchAlsup1 wrote:
On Tue, 11 Mar 2025 18:15:06 +0000, Stephen Fuld wrote:
On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
When you do change names, can you spell LD and ST instead of MOV ??
>
Yes, please LD / ST it is so much clearer what is going on. Less trouble
getting confused by the placement of operands.
>
I always put the memory operand second, which breaks the pattern of
having the destination operand first. Otherwise the destination is
first.
>
I go cross-eyed reading code that is a whole lot of moves.
>
I agree.
>
I wonder if the different preferences is at least partially due to
whether the person has a hardware or a software background?
Even when both LD and ST are written MOV there is a different OpCode
for the inbound MOV versus the outbound MOV, so, in effect, they are
really different instructions requiring different pipeline semantics.
Only (O N L Y) when one has a memory to memory move instruction can
the LDs and STs be MOVs. VAX had this, BJX* does not.
This gives me an idea:
BJXG-ISA
Presumably does not trigger Google, and also seems to not already be in use for other stuff...
So, at least "slightly less bad"...
Granted, still contains an undesirable letter pair, so maybe still subject to "Scunthorpe Effect" style content filtering.
Then again, maybe the letter pairing might be related to the relative lack of search results. Well, and/or, people do actually avoid its use in things like product or organization names, etc...
One should argue that different pipeline semantics requires a different
OpCode--and you already have said OpCode having different bit patterns
and different signedness semantics different translation access rights
, ... At the HW level about the only thing LD has in common with ST is
the way the address is generated--although MIPS did something different.
Possibly true.
Main thing that is common is ASM syntax path:
BJX syntax derived from SH syntax;
SH syntax derived from M68K syntax (as did MSP430);
M68K syntax derived from PDP-11 or VAX syntax.
Looking at stuff, it seems likely (probably outside the range of random chance) that some aspects of SuperH were influenced by VAX, and some amount of this carried over into the design of BJX.
Granted, even if functionally, they are almost entirely different (and functionally there is more in common with RISC-V, which seems more derived from the MIPS lineage...).
Well, there is an obvious difference, in that where BJX uses:
(R8, R11)
VAX had used:
(R8)[R11]
But, this bit of syntax seemingly did not make it into the SH ASM syntax.
It looks like '@' in VAX also meant deferred/indirect addressing, which was not a thing in SH, but SH ASM had still usually used '@' on memory operands (which I had dropped, as the parenthesis seemed sufficient to know that one was accessing memory).
Like, if one has:
@R4, @(R4), and (R4)
And, they all do basically the same thing, why not reduce to just:
(R4)
...
Though, the assembler will still accept @R4 if one wants to write it that way.
The (R4)+ and -(R4) notations still sorta exist (as do @R4+ and @-R4 ), but don't actually exist at the ISA level (they are broken apart into multiple instructions). Though, this logic doesn't exist along the RISC-V and XG3 paths (usage of these was mostly good and dead before I got around to adding these; and the use of different ABIs does limit the sharing of ASM between XG1/XG2 and RV/XG3).
If really needed, could add the boilerplate to crack these instructions if one tries to do this in RISC-V mode...
But, other option being to migrate over to just using the native RISC-V ASM syntax...
At present, BGBCC will run stats on the ASM to try to figure which ASM variant is being used (this applies at the scope of an entire ASM blob, so trying to mix/match ASM syntax is not likely to go well).
Well, also there is another difference that BGBCC uses MSVC/Borland style inline ASM.
__asm {
LD X10, 8(X10)
};
Rather than GCC style:
__asm("ld x10, 8(x10)");
Currently, using RISC-V ASM syntax for XG1 or XG2 isn't really a thing though...
The idea is
that when hardware guys see the instruction, they think in terms of
register ports (read versus write), what is required of the memory
system (somewhat different for loads versus stores), etc. However
software guys think of a language construct, e.g. X = Y, which is
MARY and MARY2 used X = Y to mean the value in X is deposited into Y.
Both were left to right only languages. This should surprise most !!
{{Although to be fair, Mary used the =: operator to perform assign.}}
It took me 40 years of writing specifications to get to the point where
I can write a specification such that neither the uninformed benevolent
reader nor the malicious engineer can misread that specification. MOV
is one of those things that makes getting the specification perfect
harder--and down the road, you too will figure out why I carry this
torch ...
To me it seems like mostly a historical split.
Is mildly annoying for things like ASM parsing though, as there are cases where things can be ambiguous, and the assembler getting things like argument ordering wrong is not ideal.
logically a move. I don't know if this is right, but I think it is
interesting.
>
A somewhat related question, if one wants to copy the contents of R3
into R2, is that a load or a store? :-)
In several RISC ISAs it is an ADD #0 or OR #0, however, in My 66000
we get a MOV instruction (reg-reg only) as a degenerate version of
the CMOV instruction {Hey, fell out for free}
XG1/XG2 has "MOV Rm, Rn" as its own instruction.
For RV, it is "ADDI Xd, Xm, 0".
For XG3, I mostly went with "ADD Rm, ZZR, Rn" (or "ADD Xd, Xm, ZERO") as canonical, with the decoder also recognizing this as a MOV-RR.
In both cases, a special-case recognizer is useful as MOV-RR is 1-cycle whereas ADD is 2 cycle.
For XG3, the use of 2R or 2RI ops is demoted if a 3R or 3RI op can also be used for the same purpose (the opposite of XG1 and XG2, which prioritize the use or 2R or 2RI over 3R or 3RI when equivalent, except in cases where the 2RI encodings have been deprecated due to being redundant in XG2; so "ADD Rn, Rm, Rn" would be used in preference to "ADD Rm, Rn" in XG2, but not in XG1 since the 2R form can potentially be collapsed down to a 16-bit encoding).
Also most 2RI forms were effectively dropped in XG3.
...
Why VAX Was the Ultimate CISC and Not RISC
Re: Why VAX Was the Ultimate CISC and Not RISC
