This is surely not very important for most people, because few
people read assembler, and fewer write it, but it is a part
of designing an ISA.

Reading assembler for a few architectures over the years, I have
formed a few preferences that I would like to share, with the firm
expectation that others will have different preferences :-)

Instruction names:

If two instructions have a different encoding, they should have a
different name. Apart from making an assembler marginally easier
to write, this also makes clear what size an instruction is, if
it has immediates.

Instruction names should be as regular as possible, made up of

- prefix, for example when special registers are accessed
- operation
- postfix indicating data size or other speciaities
(like immediate data)

Ideally, I'd like to be able to look at an instruction I have not
seen before and recognize it, or write it based on the structure
of the instruction names when I only remember similar instructions.
A single regexp for all instructions splitting the parts above
in a unique way would be great.

And I don't like dots in instructions.

Load and store should be called some variant of load and store,
not move, and especially not move based on the type of the
operands.

(The above looks a lot like POWER, but see below).

Assembler syntax:

Registers should be clearly visible, not encoded into numbers like
IBM likes to do. Syntax of arithmetic should be

instr r_target,operand, ...

while load and store should have the register first.

I "grew up" on the AT&T syntax (well, after 6502 assembler, which
hardly counts), so I am used to the offset(register) convention,
but I can see why [register,offset] is more clear, so I have
no clear preference there. I just find the Intel BYTE PTR stuff
strange to look at.

Comments? Other preferences? :-)

Thomas Koenig wrote:
> This is surely not very important for most people, because few
> people read assembler, and fewer write it, but it is a part
> of designing an ISA.
>
> Reading assembler for a few architectures over the years, I have
> formed a few preferences that I would like to share, with the firm
> expectation that others will have different preferences :-)
>
> Instruction names:
>
> If two instructions have a different encoding, they should have a
> different name. Apart from making an assembler marginally easier
> to write, this also makes clear what size an instruction is, if
> it has immediates.

So this means that you want separate names for a 16-bit short form vs
32-bit long form operation, even if they are doing the exact same op?

>
> Instruction names should be as regular as possible, made up of
>
> - prefix, for example when special registers are accessed
> - operation
> - postfix indicating data size or other speciaities
> (like immediate data)

The postfix (or Intel "byte ptr" prefix) is only needed when you don't
have a size implied by register name/type.

>
> Ideally, I'd like to be able to look at an instruction I have not
> seen before and recognize it, or write it based on the structure
> of the instruction names when I only remember similar instructions.
> A single regexp for all instructions splitting the parts above
> in a unique way would be great.

OK.
>
> And I don't like dots in instructions.

Strong plus here.

> Load and store should be called some variant of load and store,
> not move, and especially not move based on the type of the
> operands.

This is a "don't care" for me, either is fine.
>
> (The above looks a lot like POWER, but see below).
>
> Assembler syntax:
>
> Registers should be clearly visible, not encoded into numbers like

Yes!

> IBM likes to do. Syntax of arithmetic should be
>
> instr r_target,operand, ...
>
> while load and store should have the register first.

This is completely wrong!

If you encode all other operations with the target on the left, then you
have to do the same for a store op!
>
> I "grew up" on the AT&T syntax (well, after 6502 assembler, which
> hardly counts), so I am used to the offset(register) convention,
> but I can see why [register,offset] is more clear, so I have
> no clear preference there. I just find the Intel BYTE PTR stuff
> strange to look at.

In almost all (optimized) asm, the byte/word/dword ptr stuff is
superfluous, it is only when you do mem-mem or mem-immediate operations
that you need them.

I.e. after running out of registers in an inner loop, I might have to
increment a memory counter:

inc word ptr [cnt]
or
add word ptr [cnt]

but both of those can be avoided if [cnt] has been previously declared
as a word variable.

>
> Comments? Other preferences? :-)

I like to indent all branch instructions, sort of the opposite to the
standard HLL block indent, it still makes these operations stand out.

Terje

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

On 2/26/2022 1:11 AM, Thomas Koenig wrote:
> This is surely not very important for most people, because few
> people read assembler, and fewer write it, but it is a part
> of designing an ISA.
>
> Reading assembler for a few architectures over the years, I have
> formed a few preferences that I would like to share, with the firm
> expectation that others will have different preferences :-)
>
> Instruction names:
>
> If two instructions have a different encoding, they should have a
> different name. Apart from making an assembler marginally easier
> to write, this also makes clear what size an instruction is, if
> it has immediates.
>
> Instruction names should be as regular as possible, made up of
>
> - prefix, for example when special registers are accessed
> - operation
> - postfix indicating data size or other speciaities
> (like immediate data)
>
> Ideally, I'd like to be able to look at an instruction I have not
> seen before and recognize it, or write it based on the structure
> of the instruction names when I only remember similar instructions.
> A single regexp for all instructions splitting the parts above
> in a unique way would be great.

Or you can make the asm be similar to the syntax of a HLL, arguably more
familiar to most readers than a traditional asm syntax, even one with
your suggestions.

The case in hand: conAsm is syntactically C++, using overloading of
operators. Asm instructions are C++ functions using C++ "foo(bar1, bar2,
....)" functional notation.

Asm mnemonics are constructed from the same instruction specification as
are the code generators, simulator, and hardware. A single specification
gives a list of attributes that are relevant to the instruction;
attributes to be supported are expressed as values drawn from an
enumeration, or (notational convenience) as the whole enumeration
implying every element. The instruction is defined for the cross product
of all relevant attributes. Sample:

opPattern(exuBlock, floorOp) << floats << exuArg,
Here "floorOp" is a member of the opCode enumeration, and "floats" is
the whole of "enum floats{binFloat, decFloat}".

Each attribute enum value has a related mnemonic string. Here, the
string for floorOp is "floor" (surprise), while that for binFloat is "f"
and decFloat is "d". The whole instruction mnemonic is just the
concatenation of these strings, so this specification defines the
mnemonics "floorf" and "floord". The remainder of the instruction
specification gives the parts that are explicit arguments instead of
being implied by the mnemonic; "exuArg" (specified elsewhere) says that
the argument is a belt value evaluated in exuPhase, so the full syntax
recognized by the assembler will be for example "floorf(b7)".

Because each attribute has its own mnemonic fragment, and they are
always glued together in the same way, our system seems to necessarily
satisfy your regularity recommendations. Whether functional notation is
a bug or a feature lies in the eye of the reader, but it is certainly
readable.

> instr r_target,operand, ...

That's my pet peeve of asm syntax: you need to know the asm's typical
conventions before you can tell which operand plays which role.
I much prefer it when the source and destination are syntactically
distinct, maybe with

add x <- y, z

or

add x, z -> z

-- Stefan

On Saturday, February 26, 2022 at 3:11:18 AM UTC-6, Thomas Koenig wrote:
> This is surely not very important for most people, because few
> people read assembler, and fewer write it, but it is a part
> of designing an ISA.
>
> Reading assembler for a few architectures over the years, I have
> formed a few preferences that I would like to share, with the firm
> expectation that others will have different preferences :-)
>
> Instruction names:
>
> If two instructions have a different encoding, they should have a
> different name. Apart from making an assembler marginally easier
> to write, this also makes clear what size an instruction is, if
> it has immediates.
<
Then you would be eating up a lot of namespace in the programmers head::
<
ADD R7,R4,R19
ADD R7,R4,-R19
ADD R7,-R4,-R19
ADD R7,R4,#256
ADD R7,R4,#-256
ADD R7,#256,R19
ADD R7,#-256,R19
ADD R7,R4,#0x12345678
ADD R7,R4,#0x1234567890123456
ADD R7,#0x12345678,R19
ADD R7,#0x1234567890123456,R19
<
You eat up a lot of namespace whereas you could completely minimize the
namespace consumption and allow the ASCII express itself.
<
And I left out the Overflow checking versions and the unsigned distinctions.
<
AND: this is only 1 instruction. Yet, the ASCII is completely readable
to anyone who has ever read assembly language code before. More
importantly, the surprise factor is near zero.
>
> Instruction names should be as regular as possible, made up of
>
> - prefix, for example when special registers are accessed
> - operation
> - postfix indicating data size or other speciaities
> (like immediate data)
<
Only memory references have size and signedness, everything
else is 64-bits (except for 32-bit floats)
>
> Ideally, I'd like to be able to look at an instruction I have not
> seen before and recognize it, or write it based on the structure
> of the instruction names when I only remember similar instructions.
> A single regexp for all instructions splitting the parts above
> in a unique way would be great.
>
> And I don't like dots in instructions.
>
> Load and store should be called some variant of load and store,
> not move, and especially not move based on the type of the
> operands.
<
Here I completely agree. MOV is reg-to-reg, LD brings forth from
memory, ST sends towards memory.
>
> (The above looks a lot like POWER, but see below).
>
> Assembler syntax:
>
> Registers should be clearly visible, not encoded into numbers like
> IBM likes to do. Syntax of arithmetic should be
>
> instr r_target,operand, ...
>
> while load and store should have the register first.
<
The official name of a register in My 66000 is R[index] where index
goes from 0..31. The assembler has a set of Macros that capture
R0..R31, with aliases for FP = R[30] and SP = R[31]. In memory
reference instructions one can write:: LD Rd,[IP+immed]; using
the current IP as the base register.
<
Your proposal would need LDIP of all 8 flavors and STIP of another
4 flavors
>
> I "grew up" on the AT&T syntax (well, after 6502 assembler, which
> hardly counts), so I am used to the offset(register) convention,
> but I can see why [register,offset] is more clear, so I have
> no clear preference there. I just find the Intel BYTE PTR stuff
> strange to look at.
>
> Comments? Other preferences? :-)
<
Let architects define their own instruction sets.

"Thomas Koenig" wrote in message
news:svcqrj$jj6$1@newsreader4.netcologne.de...

> Instruction names:

> If two instructions have a different encoding, they should have a
> different name. Apart from making an assembler marginally easier
> to write, this also makes clear what size an instruction is, if
> it has immediates.

How do you propose to distinguish between

AND RAX, RBX

and

AND RAX, RBX

The first is encoded as REX.W + 21 /r and the second as REX.W + 23 /r?
Kind of nice for steganogrphy :)

James Van Buskirk <not_valid@comcast.net> schrieb:
> "Thomas Koenig" wrote in message
> news:svcqrj$jj6$1@newsreader4.netcologne.de...
>
>> Instruction names:
>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
>
> How do you propose to distinguish between
>
> AND RAX, RBX
>
> and
>
> AND RAX, RBX
>
> The first is encoded as REX.W + 21 /r and the second as REX.W + 23 /r?

Sorry, I don't understand what you mean. Who or what is REX.W and what
does + 21 /r and + 23 /r mean?

On Saturday, February 26, 2022 at 12:27:11 PM UTC-6, Thomas Koenig wrote:
> James Van Buskirk <not_...@comcast.net> schrieb:
> > "Thomas Koenig" wrote in message
> > news:svcqrj$jj6$1...@newsreader4.netcologne.de...
> >
> >> Instruction names:
> >
> >> If two instructions have a different encoding, they should have a
> >> different name. Apart from making an assembler marginally easier
> >> to write, this also makes clear what size an instruction is, if
> >> it has immediates.
> >
> > How do you propose to distinguish between
> >
> > AND RAX, RBX
> >
> > and
> >
> > AND RAX, RBX
> >
> > The first is encoded as REX.W + 21 /r and the second as REX.W + 23 /r?
> Sorry, I don't understand what you mean. Who or what is REX.W and what
> does + 21 /r and + 23 /r mean?
<
They are MOD/RMs that lead to the same actual calculation.

It appears that James Van Buskirk <not_valid@comcast.net> said:
>"Thomas Koenig" wrote in message
>news:svcqrj$jj6$1@newsreader4.netcologne.de...
>
>> Instruction names:
>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
>
>How do you propose to distinguish between
>
>AND RAX, RBX
>
>and
>
>AND RAX, RBX

Personally, I don't.

>The first is encoded as REX.W + 21 /r and the second as REX.W + 23 /r?
>Kind of nice for steganogrphy :)

I understand that the difference is that the first allows the form general,register
and the second is register,general, and since the general operand can be a register
they are two ways to do the same thing.

Not having looked at much assembler output lately, which one will assemblers use?
Is there a way to force the other?

There are a lot of other redundant encodings, e.g., register indirect with or
without the SIB byte. I assume the assembler prefers the shorter version but
is there a way to force it to use the other one?

--
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 2/26/2022 3:17 AM, Ivan Godard wrote:
> On 2/26/2022 1:11 AM, Thomas Koenig wrote:
>> This is surely not very important for most people, because few
>> people read assembler, and fewer write it, but it is a part
>> of designing an ISA.
>>
>> Reading assembler for a few architectures over the years, I have
>> formed a few preferences that I would like to share, with the firm
>> expectation that others will have different preferences :-)
>>
>> Instruction names:
>>
>> If two instructions have a different encoding, they should have a
>> different name.  Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
>>
>> Instruction names should be as regular as possible, made up of
>>
>> - prefix, for example when special registers are accessed
>> - operation
>> - postfix indicating data size or other speciaities
>>    (like immediate data)
>>
>> Ideally, I'd like to be able to look at an instruction I have not
>> seen before and recognize it, or write it based on the structure
>> of the instruction names when I only remember similar instructions.
>> A single regexp for all instructions splitting the parts above
>> in a unique way would be great.
>
> Or you can make the asm be similar to the syntax of a HLL, arguably more
> familiar to most readers than a traditional asm syntax, even one with
> your suggestions.
>
> The case in hand: conAsm is syntactically C++, using overloading of
> operators. Asm instructions are C++ functions using C++ "foo(bar1, bar2,
> ...)" functional notation.

OK, that surely works, but . . .

For non-Mill architectures, you still have the issue of the order of the
operands, e.g. is the target first or last? Is the order of "move type"
instructions always from-to? If so, while that is consistent with
typical HLL syntax, is puts the register destination for loads after the
source.

Also, while it is certainly C++/function call compatible, I note that if
you simply leave out the parentheses, and require a space after the
"function name", it is syntactically the same as a typical ASM format.

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

On 2/26/2022 3:11 AM, Thomas Koenig wrote:
> This is surely not very important for most people, because few
> people read assembler, and fewer write it, but it is a part
> of designing an ISA.
>
> Reading assembler for a few architectures over the years, I have
> formed a few preferences that I would like to share, with the firm
> expectation that others will have different preferences :-)
>

FWIW, my ASM syntax is the way it is, partly because it "evolved" out of
the syntax used by GAS when targeting SH:
OP Src, Dst

I did go from:
@Reg, @(Disp, Reg), @(Reg), ...
Mostly over to:
(Reg), (Reg, Disp), ...

Partly because I found the '@' ugly.

In practice, this was just sort of making the '@' optional and parsing
it roughly the same way as before (where both "@(Disp,Reg)" and
"@(Reg,Disp)" could be used in SH ASM, ...).

Luckily, GAS for SH did not use '%' on all over the place (as it does on
x86), which is good because putting '%' everywhere looks like crap IMHO.

I actually slightly prefer:
OP Dst, Src
OP Dst, SrcA, SrcB

Ordering, but this was hindered by the evolution path; BJX1 evolved out
of SH4; and initial forms of BJX2 were basically BJX1 but with the
instruction encoding reworked to be less of an awful mess.

Though, arguably, with the addition of XGPR it is now back to being a
mess, if albeit slightly less of a mess, because all of the "new"
encodings (XGPR, Op64, Op40x2, ...) are basically bit-twiddles of the
existing instruction spaces (and can all reuse the same decoders, 1).

1: As-is, the original 32-bit instruction decoder has in effect
internally expanded to closer to 56 bits (with some adhoc repacking on
the frontend).

Though, the annoyances with the hairy encodings aren't quite enough to
get over the hump of there basically being no way to (cleanly) repack
the ISA "as it is" into a consistent 32-bit instruction format.

Even if I give up the 16-bit encodings, by the time the instruction
format is "orthogonal" (with 6-bit register fields, WEX, 2-bit
predication, ...), I would only have a fraction of the opcode space.

The only other real option would be to redesign it around a bigger
instruction format (40 or 48 bits), but then I already have some
(currently unused) 48-bit encoding spaces in BJX2.

> Instruction names:
>
> If two instructions have a different encoding, they should have a
> different name. Apart from making an assembler marginally easier
> to write, this also makes clear what size an instruction is, if
> it has immediates.
>

Partial disagree.

I prefer to separate instructions more based on behavior than encoding,
if one forces it to be 1:1, that would be way too many mnemonics.

Things like immediate values are "obvious enough" without needing a
separate mnemonic, as 'R31' or 'X28' or similar is different than '31'.

There was also originally an '#' prefix for number immediates, but I
ended up mostly dropping this for similar reasons to '@', as well as
mixing poorly with the C preprocessor and the MSVC / Borland style
inline ASM (GCC style inline ASM is ugly).

In some cases, it gets a little abstract, as in:
MOV Immed, Rn

Can actually be mapped to any number of things by the assembler, as MOV
in this context is more interpreted as "get this constant loaded into
this register, I don't care how".

In the ISA listing, there is instead LDI/LDIZ/LDIN/LDIQ/... but, these
more reflect "how" the CPU gets the value loaded, as expressing all of
these cases as "MOV" would get a bit ambiguous.

The person writing ASM probably doesn't need to care as much how the
constant gets loaded into the register, or the optimal way to do so
(Does the target have Jumbo-Load encoding? Can it be expressed as a
Binary16 immediate? ...). The assembler can deal with this part.

Unlike ARM/Thumb, no '=' prefix is used, because the '=' is also kinda
pointless IMO.

> Instruction names should be as regular as possible, made up of
>
> - prefix, for example when special registers are accessed
> - operation
> - postfix indicating data size or other speciaities
> (like immediate data)
>
> Ideally, I'd like to be able to look at an instruction I have not
> seen before and recognize it, or write it based on the structure
> of the instruction names when I only remember similar instructions.
> A single regexp for all instructions splitting the parts above
> in a unique way would be great.
>

Fair enough.

> And I don't like dots in instructions.
>

It is a tradeoff. In my case, they were also inherited from SH ASM:
MOV.B, MOV.L, ...
They had also used other characters in instruction names:
CMP/GE, FCMP/EQ, ...

I generally dropped the '/' though, and in some cases the '.' is optional:
'SHLDQ' is equivalent to 'SHLD.Q'.

While it could be possible to go over to RISC-V style naming for
Load/Store ops, there isn't a huge reason to do so when the distinction
can be determined syntactically.

Say:
(Rm) or [Rm] //We know already this is memory
Rm //Bare register name is not memory

It makes more sense for an assembler which does not have special
notation for memory access, or if the order is ambiguous:
LDB X17, X13, 208
STB X17, X15, 252
OK, whatever then...

> Load and store should be called some variant of load and store,
> not move, and especially not move based on the type of the
> operands.
>
> (The above looks a lot like POWER, but see below).
>
> Assembler syntax:
>
> Registers should be clearly visible, not encoded into numbers like
> IBM likes to do. Syntax of arithmetic should be
>
> instr r_target,operand, ...
>
> while load and store should have the register first.
>

Something like:
MOVQ R23, (R28)
MOVQ (R30), R23

Would be "good enough" IMO.

For ASM, I also prefer simple untyped registers (though, within BGBCC,
register types come up in some contexts).

Namely:
R0..R63: Basic Register, Context-Dependent
RD0..RD63: Register holds a 32-bit value (assumes sign-extended)
RQ0..RQ63: Register holds a 64-bit value
LR0..LR31: Holds a register pair (Odd encodes R32..R63)
X0..X31: R0..R31, but in "RISC-V Mode" (1)

1: Decided mostly to not go into this pile of hacks. Like, even if it
isn't all that expensive on the FPGA side, the hackery involved is kinda
ugly (and whether or not this is "sane" is yet to be determined).

> I "grew up" on the AT&T syntax (well, after 6502 assembler, which
> hardly counts), so I am used to the offset(register) convention,
> but I can see why [register,offset] is more clear, so I have
> no clear preference there. I just find the Intel BYTE PTR stuff
> strange to look at.
>

All the "BYTE PTR", "DWORD PTR", ... stuff is borderline useless even in
x86.

There are only a rare few cases where it actually matters, and for
pretty much everything else they are unnecessary fluff.

> Comments? Other preferences? :-)
>

On 2/26/2022 11:55 AM, MitchAlsup wrote:
> On Saturday, February 26, 2022 at 3:11:18 AM UTC-6, Thomas Koenig wrote:
>> This is surely not very important for most people, because few
>> people read assembler, and fewer write it, but it is a part
>> of designing an ISA.
>>
>> Reading assembler for a few architectures over the years, I have
>> formed a few preferences that I would like to share, with the firm
>> expectation that others will have different preferences :-)
>>
>> Instruction names:
>>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
> <
> Then you would be eating up a lot of namespace in the programmers head::
> <
> ADD R7,R4,R19
> ADD R7,R4,-R19
> ADD R7,-R4,-R19
> ADD R7,R4,#256
> ADD R7,R4,#-256
> ADD R7,#256,R19
> ADD R7,#-256,R19
> ADD R7,R4,#0x12345678
> ADD R7,R4,#0x1234567890123456
> ADD R7,#0x12345678,R19
> ADD R7,#0x1234567890123456,R19
> <
> You eat up a lot of namespace whereas you could completely minimize the
> namespace consumption and allow the ASCII express itself.
> <
> And I left out the Overflow checking versions and the unsigned distinctions.
> <
> AND: this is only 1 instruction. Yet, the ASCII is completely readable
> to anyone who has ever read assembly language code before. More
> importantly, the surprise factor is near zero.

Likewise, similar issue:
ADD Rm, Rn //16-bit
ADD Rm, Rn //32-bit
ADD Imm16u, Rn
ADD Imm16n, Rn
ADD Rm, Ro, Rn
ADD Rm, Imm9u, Rn
ADD Rm, Imm9n, Rn

Add in a few more variants with Jumbo and Op64 encodings.
ADD Rm, Ro, Rn //XGPR (R0..R63)
ADD Rm, Ro, Rn //Op64, like XGPR but twice as big
ADD Rm, Imm33s, Rn //Jumbo
ADD Rm, Imm17s, Rn //Op64 (R0..R63)
...

Add more if one considers the predicated forms as separate instructions
(rather than alternate encodings of the same instruction).

....

I don't actually bother to include most of these variants in the
listings, since they can be inferred from the encoding rules.

The CPU doesn't really care much either, in terms of the main decoder,
it might see:
It is in the F0 Block,
Its second word matches the pattern: 16'h1zz0 (ADD Rm, Ro, Rn).
It is in the F2 Block,
Its second word matches the pattern: 16'h0zzz (ADD Rm, Imm, Rn).
...

That there are 10+ encoding paths which happen to land in the F0 block,
doesn't really matter all that much.

Well, and the EX stages sees:
NMID=ALU3R, UCIX=ADD
The EX stages and ALU don't really care how we got there.

Trying to list out every encoding of every instruction would likely be
impractical.

ADD Rm, Ro, Rn
F0nm_1eo0 (Base)
F4nm_1eo0 (WEX)
E0nm_1eo0 (?T)
E4nm_1eo0 (?F)
EAnm_1eo0 (WEX?T)
EEnm_1eo0 (WEX?F)
7wnm_1eo0 (XGPR), Ww=0
7Wnm_1eo0 (XGPR, WEX), Ww=1
FFw0_0vii_F0nm_1eo0 (Op64)
FFw0_0vii_F4nm_1eo0 (WEX, Reserved)
FFw0_0vii_E0nm_1eo0 (?T)
FFw0_0vii_E4nm_1eo0 (?F)
FFw0_0vii_EAnm_1eo0 (WEX?T, Reserved)
FFw0_0vii_EEnm_1eo0 (WEX?F, Reserved)

FFw0_0Vii_F0nm_1eo0 (Op64), Vv=1 (N/A 2)
FFw0_0Vii_F4nm_1eo0 (WEX, Reserved), Vv=1 (N/A 2)
FFw0_0Vii_E0nm_1eo0 (?T), Vv=1 (N/A 2)
FFw0_0Vii_E4nm_1eo0 (?F), Vv=1 (N/A 2)
FFw0_0Vii_EAnm_1eo0 (WEX?T, Reserved), Vv=1 (N/A 2)
FFw0_0Vii_EEnm_1eo0 (WEX?F, Reserved), Vv=1 (N/A 2)

FEjj_jjjj_F0nm_1eo0 (Jumbo, N/A 2)
FEjj_jjjj_F4nm_1eo0 (WEX, Reserved)
FEjj_jjjj_E0nm_1eo0 (?T, N/A 2)
FEjj_jjjj_E4nm_1eo0 (?F, N/A 2)
FEjj_jjjj_EAnm_1eo0 (WEX?T, Reserved)
FEjj_jjjj_EEnm_1eo0 (WEX?F, Reserved)

...
Then repeat a bunch of these again for the Op40x2 Encodings.
78ww_vvii_F4nm_1eo0_F0nm_1eo0
...
Maybe add Jumbo96 variants for good measure...
FEjj_jjjj_FEjj_jjjj_F0nm_1eo0 (Yeah...)
...
Maybe add Jumbo+Op64 variants (Reserved, but whatever)
FEjj_jjjj_FFw0_0vii_F0nm_1eo0 (...)
...
...

N/A 2: Technically Valid, but N/A for this instruction, thus reserved.

And, "ADD Rm, Imm, Rn" (F2) or "ADD Imm, Rn" (F2|F8) would have an
entirely different set of patterns.

The assembler doesn't need to deal with every possible case either, it
generates the base encoding, and then modifies it into the needed form
(or fails if the instruction can't be repacked into the requested form).

Granted, one can't really do a naive "count instructions and multiply by
4 to get code size" with this.

>>
>> Instruction names should be as regular as possible, made up of
>>
>> - prefix, for example when special registers are accessed
>> - operation
>> - postfix indicating data size or other speciaities
>> (like immediate data)
> <
> Only memory references have size and signedness, everything
> else is 64-bits (except for 32-bit floats)

More or less similar.

I have:
32-bits, sign or zero extended to 64 bits
64-bits, native
128-bits, register pair

Where relevant, instructions use suffix modifiers:
L: 32-bit variant.
Q: 64-bit variant
X: 128-bit variant
In a few cases, the X has been used as a prefix:
XMOV / XMOV.x
Mostly because putting it as a suffix would be ambiguous.

>>
>> Ideally, I'd like to be able to look at an instruction I have not
>> seen before and recognize it, or write it based on the structure
>> of the instruction names when I only remember similar instructions.
>> A single regexp for all instructions splitting the parts above
>> in a unique way would be great.
>>
>> And I don't like dots in instructions.
>>
>> Load and store should be called some variant of load and store,
>> not move, and especially not move based on the type of the
>> operands.
> <
> Here I completely agree. MOV is reg-to-reg, LD brings forth from
> memory, ST sends towards memory.

I require a type suffix for Load / Store.

Bare 'MOV' is limited to RegReg or ImmReg and similar.

I did merge it down some, vs SH:
LDS, STS, LDC, STC

Which were all folded into MOV:
MOV LR, R1
MOV R3, GBR
...
Obvious enough, don't need special mnemonics.

Assembler can see that I am using LR or GBR and figure this detail out
on its own.

>>
>> (The above looks a lot like POWER, but see below).
>>
>> Assembler syntax:
>>
>> Registers should be clearly visible, not encoded into numbers like
>> IBM likes to do. Syntax of arithmetic should be
>>
>> instr r_target,operand, ...
>>
>> while load and store should have the register first.
> <
> The official name of a register in My 66000 is R[index] where index
> goes from 0..31. The assembler has a set of Macros that capture
> R0..R31, with aliases for FP = R[30] and SP = R[31]. In memory
> reference instructions one can write:: LD Rd,[IP+immed]; using
> the current IP as the base register.
> <
> Your proposal would need LDIP of all 8 flavors and STIP of another
> 4 flavors

As noted, I have:
(Rm,Disp)
(Rm,Ri)
I could have used:
[Rm+Disp]
[Rm+Ri*Sc]

But, either way.

>>
>> I "grew up" on the AT&T syntax (well, after 6502 assembler, which
>> hardly counts), so I am used to the offset(register) convention,
>> but I can see why [register,offset] is more clear, so I have
>> no clear preference there. I just find the Intel BYTE PTR stuff
>> strange to look at.
>>
>> Comments? Other preferences? :-)
> <
> Let architects define their own instruction sets.

"Thomas Koenig" wrote in message
news:svdrds$bu1$1@newsreader4.netcologne.de...

> James Van Buskirk <not_valid@comcast.net> schrieb:

> > How do you propose to distinguish between

> > AND RAX, RBX

> > and

> > AND RAX, RBX

> > The first is encoded as REX.W + 21 /r and the second as REX.W + 23 /r?

> Sorry, I don't understand what you mean. Who or what is REX.W and what
> does + 21 /r and + 23 /r mean?

REX.W means to use the REX prefix and indicates an instruction with 64-bit,
rather than 32-bit, registers. This is INT(Z'48',INT8).
The +21 or +23 mean opcode bytes, thus INT(Z'21',INT8) or INT(Z'23',INT8).
The /r means bits 3:4 of the MOD R/M bytes refer to the register; when
bits 6:7 == B'11', the other argument is a register as well. The bits 0:2
refer
to that register.
RAX is register B'000' and RBX is register B'011' (I know :( ) so the MOD
R/M
bytes in the first instance comes out to be 11 011 000 = INT(Z'D8',INT8) and
int the second case it's 11 000 011 = INT(Z'C3',INT8).
Thus we can encode

AND RAX, RBX

as

db 48h, 21h, 0D8h

or

db 48h, 23h, 0C3h

I found https://defuse.ca/online-x86-assembler.htm#disassembly2
to be convenient for checking this.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 2/26/2022 1:11 AM, Thomas Koenig wrote:
>> This is surely not very important for most people, because few
>> people read assembler, and fewer write it, but it is a part
>> of designing an ISA.
>>
>> Reading assembler for a few architectures over the years, I have
>> formed a few preferences that I would like to share, with the firm
>> expectation that others will have different preferences :-)
>>
>> Instruction names:
>>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
>>
>> Instruction names should be as regular as possible, made up of
>>
>> - prefix, for example when special registers are accessed
>> - operation
>> - postfix indicating data size or other speciaities
>> (like immediate data)
>>
>> Ideally, I'd like to be able to look at an instruction I have not
>> seen before and recognize it, or write it based on the structure
>> of the instruction names when I only remember similar instructions.
>> A single regexp for all instructions splitting the parts above
>> in a unique way would be great.
>
> Or you can make the asm be similar to the syntax of a HLL, arguably more
> familiar to most readers than a traditional asm syntax, even one with
> your suggestions.
>
> The case in hand: conAsm is syntactically C++, using overloading of
> operators. Asm instructions are C++ functions using C++ "foo(bar1, bar2,
> ...)" functional notation.

How does that look in detail? would you have (assuming conditional
registers, which I know the Mill does not have)

r1 = add(r2,r3)

or

add (r1,r2,r3)

? The latter would not be an advantage over conventional assembler,
IMHO.

Can you maybe share a few examples?

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, February 26, 2022 at 3:11:18 AM UTC-6, Thomas Koenig wrote:
>> This is surely not very important for most people, because few
>> people read assembler, and fewer write it, but it is a part
>> of designing an ISA.
>>
>> Reading assembler for a few architectures over the years, I have
>> formed a few preferences that I would like to share, with the firm
>> expectation that others will have different preferences :-)
>>
>> Instruction names:
>>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
><
> Then you would be eating up a lot of namespace in the programmers head::
><
> ADD R7,R4,R19
> ADD R7,R4,-R19
> ADD R7,-R4,-R19
> ADD R7,R4,#256
> ADD R7,R4,#-256
> ADD R7,#256,R19
> ADD R7,#-256,R19
> ADD R7,R4,#0x12345678
> ADD R7,R4,#0x1234567890123456
> ADD R7,#0x12345678,R19
> ADD R7,#0x1234567890123456,R19

I agree that it would make less sense for your ISA than
for a more conventional RISC.

[...]

>> Comments? Other preferences? :-)
><
> Let architects define their own instruction sets.

Obviously :-)

John Dallman <jgd@cix.co.uk> schrieb:
> In article <svcqrj$jj6$1@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> If two instructions have a different encoding, they should have a
>> different name. Apart from making an assembler marginally easier
>> to write, this also makes clear what size an instruction is, if
>> it has immediates.
>
> This hinges on what an assembly language is optimised for. Is it a
> higher-level expression of a sequence of instructions, or a low-level
> representation of a program? Those aren't quite the same thing, although
> assembly languages do both duties.

I would say the latter, except when using macros.

> Your view makes perfect sense for a processor designer. I'm someone who
> reads assembly listings and debugger disassembly to figure out where a
> compiler bug has shown up.

I do that as well, but I am also looking for inefficient encoding.

On 2/27/2022 12:30 PM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 2/26/2022 1:11 AM, Thomas Koenig wrote:
>>> This is surely not very important for most people, because few
>>> people read assembler, and fewer write it, but it is a part
>>> of designing an ISA.
>>>
>>> Reading assembler for a few architectures over the years, I have
>>> formed a few preferences that I would like to share, with the firm
>>> expectation that others will have different preferences :-)
>>>
>>> Instruction names:
>>>
>>> If two instructions have a different encoding, they should have a
>>> different name. Apart from making an assembler marginally easier
>>> to write, this also makes clear what size an instruction is, if
>>> it has immediates.
>>>
>>> Instruction names should be as regular as possible, made up of
>>>
>>> - prefix, for example when special registers are accessed
>>> - operation
>>> - postfix indicating data size or other speciaities
>>> (like immediate data)
>>>
>>> Ideally, I'd like to be able to look at an instruction I have not
>>> seen before and recognize it, or write it based on the structure
>>> of the instruction names when I only remember similar instructions.
>>> A single regexp for all instructions splitting the parts above
>>> in a unique way would be great.
>>
>> Or you can make the asm be similar to the syntax of a HLL, arguably more
>> familiar to most readers than a traditional asm syntax, even one with
>> your suggestions.
>>
>> The case in hand: conAsm is syntactically C++, using overloading of
>> operators. Asm instructions are C++ functions using C++ "foo(bar1, bar2,
>> ...)" functional notation.
>
> How does that look in detail? would you have (assuming conditional
> registers, which I know the Mill does not have)
>
> r1 = add(r2,r3)
>
> or
>
> add (r1,r2,r3)
>
> ? The latter would not be an advantage over conventional assembler,
> IMHO.
>
> Can you maybe share a few examples?

Source:
int a;
int foo(int b, int c) {
if ((b&14) == 0)
a = c - 1414;
else
b += c;
return b;
}

Compiled conAsm:
F("foo") %0 %1;
formals() %0 %1,
rd(w(1414)) %7,
sub(b2 %1, b0 %7) %4,
eqlb() %3, andl(b2 %0, 14) %2,
storetr(b3 %4, dp, gl("a"), b2 %3),
add(b5 %1, b4 %0) %6,
retnfl(b2 %3, b0 %6),
retn(b5 %0);

Edited to remove compiler-generated documentary comment, such as source
line/column numbers, belt event activity description, etc. I have left
in the "%N" belt value identifiers, although these can be omitted in
manual asm (only the "bN" temporal indices are necessary).

Note that this function comprises one bundle and takes one cycle to
execute on a low-midrange Mill.

It appears that Ivan Godard <ivan@millcomputing.com> said:
>Or you can make the asm be similar to the syntax of a HLL, arguably more
>familiar to most readers than a traditional asm syntax, even one with
>your suggestions.

I liked PL360 which was a S/360 assembler with a syntax similar to Algol.
Wirth used it to write Algol W. I used it some around 1970 at Princeton
which let people run small PL360 and AlgolW programs without needing an account.
I don't think they realized that PL360 was an assembler so you could write some
rather naughty programs if you wanted to.

http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf

--
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 2/27/2022 3:53 PM, John Levine wrote:
> It appears that Ivan Godard <ivan@millcomputing.com> said:
>> Or you can make the asm be similar to the syntax of a HLL, arguably more
>> familiar to most readers than a traditional asm syntax, even one with
>> your suggestions.
>
> I liked PL360 which was a S/360 assembler with a syntax similar to Algol.
> Wirth used it to write Algol W. I used it some around 1970 at Princeton
> which let people run small PL360 and AlgolW programs without needing an account.
> I don't think they realized that PL360 was an assembler so you could write some
> rather naughty programs if you wanted to.
>
> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>

The expression-assembler PL360 was the best language work Wirth ever
did. Following it there were several others done for various other ISA -
PL11, PL516, ... My own Mary language family can be seen as the bastard
child of Algol68 and PL360.

John Levine wrote:
> It appears that Ivan Godard <ivan@millcomputing.com> said:
>> Or you can make the asm be similar to the syntax of a HLL, arguably more
>> familiar to most readers than a traditional asm syntax, even one with
>> your suggestions.
>
> I liked PL360 which was a S/360 assembler with a syntax similar to Algol.
> Wirth used it to write Algol W. I used it some around 1970 at Princeton
> which let people run small PL360 and AlgolW programs without needing an account.
> I don't think they realized that PL360 was an assembler so you could write some
> rather naughty programs if you wanted to.
>
> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>

If this refers to structured assembler, yes that should be supported.
I've used structured VAX macros that implement nested
IF-THEN-ELSIF-ELSE-ENDIF and various kinds of LOOP-ENDLOOP.
That alone goes a long way to de-cluttering assembler.
So that should always be a built in assembler feature.

My preference is that branch BR and variants BSR, Bxxx is for relative
offsets, and jump JMP and variants JSR, Jxxx for absolute addresses.
I really don't like it when the syntax of the address expression is
somehow used to determine whether this is absolute or relative.
Too easy to make a mistake.
Also I have both "JMP reg" and "BR reg' instructions and variants
so it needs to be clear which is intended.

According to EricP <ThatWouldBeTelling@thevillage.com>:
>John Levine wrote:
>> I liked PL360 which was a S/360 assembler with a syntax similar to Algol. ...
>>
>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>>
>If this refers to structured assembler, yes that should be supported.

No, it was an assembler with a syntax similar to Algol.

When you looked at the report at the URL in your message, what did you think of it?

--
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

John Levine wrote:
> According to EricP <ThatWouldBeTelling@thevillage.com>:
>> John Levine wrote:
>>> I liked PL360 which was a S/360 assembler with a syntax similar to Algol. ...
>>>
>>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>>>
>> If this refers to structured assembler, yes that should be supported.
>
> No, it was an assembler with a syntax similar to Algol.
>
> When you looked at the report at the URL in your message, what did you think of it?

I hadn't looked at it... I had heard that IBM has structured assembler
in the past and was hoping that summarized its basic description.
However now that do look at it, I'd say its more of a HLL than assembler.
Reminds me of VAX Bliss, which I never wrote but read on source code
documentation microfiche.

Ivan Godard <ivan@millcomputing.com> schrieb:

> int a;
> int foo(int b, int c) {
> if ((b&14) == 0)
> a = c - 1414;
> else
> b += c;
> return b;
> }

Let me see if I can reasd this:

> Compiled conAsm:
> F("foo") %0 %1;
> formals() %0 %1,

Is this an actual instruction, or some sort of
pseudo-instruction?

> rd(w(1414)) %7,

I assume this loads a belt entry with the constant 1414.

> sub(b2 %1, b0 %7) %4,

Hm, if I understand you correctly this is

%4 = sub (b2, b0), correct? Is the target always the
last digit after the percent sign?

> eqlb() %3, andl(b2 %0, 14) %2,
> storetr(b3 %4, dp, gl("a"), b2 %3),
> add(b5 %1, b4 %0) %6,
> retnfl(b2 %3, b0 %6),
> retn(b5 %0);

Without further explanation, this is rather hard to read, certainly
not your average assembler syntax :-)

>
> Edited to remove compiler-generated documentary comment, such as source
> line/column numbers, belt event activity description, etc. I have left
> in the "%N" belt value identifiers, although these can be omitted in
> manual asm (only the "bN" temporal indices are necessary).

> Note that this function comprises one bundle and takes one cycle to
> execute on a low-midrange Mill.

That is rather impressive. It would also be interesting to know
how your compiler fares with some normal Fortran code :-)

John Levine <johnl@taugh.com> schrieb:
> It appears that Ivan Godard <ivan@millcomputing.com> said:
>>Or you can make the asm be similar to the syntax of a HLL, arguably more
>>familiar to most readers than a traditional asm syntax, even one with
>>your suggestions.
>
> I liked PL360 which was a S/360 assembler with a syntax similar to Algol.
> Wirth used it to write Algol W. I used it some around 1970 at Princeton
> which let people run small PL360 and AlgolW programs without needing an account.
> I don't think they realized that PL360 was an assembler so you could write some
> rather naughty programs if you wanted to.
>
> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf

That is an interesting piece of software.

I see they deviated from the usual meaning of

R1 := R2 + R1

which would scare me - one of FORTRAN's great achievement
was to be able to write formulas naturally. But it is
certainly the highest-level assembler I have seen yet.

According to EricP <ThatWouldBeTelling@thevillage.com>:
>>>> I liked PL360 which was a S/360 assembler with a syntax similar to Algol. ...
>>>>
>>>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf

>I hadn't looked at it... I had heard that IBM has structured assembler
>in the past and was hoping that summarized its basic description.
>However now that do look at it, I'd say its more of a HLL than assembler.
>Reminds me of VAX Bliss, which I never wrote but read on source code
>documentation microfiche.

IBM has something they call High Level Assembler or HLASM which is an ordinary assembler with
a powerful macro language in which people write some pretty fancy macros.

PL360 was an assembler because everything you wrote had a direct translation into
machine language. For example, these are not the same:

R1 := R1 + R2 // add R2 to R1
R1 := R2 + R1 // load R2 into R1, then add R1 to itself

It also has explicit ways to say what base register to use, what registers to use for
call and return, and so forth.

I never used Bliss32 but I wrote a fair amount of Bliss-10 on a PDP-10. I'd say it was half
a level up from PL360. All of the data references were in terms of the PDP-10's addressing
structure and you could insert specific instructions with pseudo-functions as in PL360, but
it was enough of a compiler to handle expressions that used temporary registers.

--
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