Allow to use `?` as `don't care` in [fields] keyword bit patterns of "spec.isa"

[arctic mesa]

This is how an OVERTURE arch compatible spec.isa could look like (not that this architecture really needs this):```
register // color the "register" with default generated color
r0 000
r1 001
r2 010
r3 011
r4 100
r5 101
in 110
out 110

instr 0x0000FF // now all instruction keywords will be pure blue
or 01???000 // In the standard implementation, these 3 bits are not checked at all;
nand 01???001 // this way we can document the exact functionality for each instruction,
nor 01???010 // or it could be useful in some disassembly view functionality
and 01???011 // that could be added to all memory components (like any RAM or SSD)
add 01???100
sub 01???101
nop 11???000
jmp 11???001
jz 11???010
jnz 11???011
jl 11???100
jge 11???101
jg 11???110
jle 11???111

// the remaining field definitions are not needed to implement the base "spec.isa"

alu_op 0xFFFFFF
| ???000
!& ???001
!| ???010
& ???011

• ???100

• ???101

cond 0xFFFFFF
=0 ???010
!=0 ???011
≠0 ???011
<0 ???100

= ???101
≥0 ???101
0 ???110
=<0 ???111
≤0 ???111

[instructions]

mov %a(register), %b(register)
10bbbaaa
Moves a value from %b to %a.

load %a(immediate|label)
00aaaaaa
Moves %a to r0.

%a(instr)
aaaaaaaa
Execute instruction %a.
If it is an ALU instruction, then evaluate it on r1 and r2 and store the result in r3.
If it is a jump instruction, then jump to r0 if r3 fulfills the instructions condition.

// That is all that is needed to express all instructions in this architecture,
// but we could modernize the syntax to make it feel a bit more like a higher level language:

%a(register) = %b(register)
10bbbaaa
Moves a value from %b to %a.

r0 = %a(immediate|label)
00aaaaaa
Moves %a to r0.

r3 = r1 %a(alu_op) r2
01aaaaaa
Execute an ALU instruction %a; evaluate %a on r1 and r2 and store the result in r3.

if r3 %a(cond) goto r0
11aaaaaa
Execute a jump instruction %a; jump to r0 if r3 fulfills the instruction %a's condition.

[fleet pendant]

Color, sure, if Stuffe agrees to support that in the frontend

More symbols is planned with string syntax, I just havn't gotten around to that

For don't cares, I really don't see the point

Even for your overture example I don't see any benefit at all - just don't have those bits be part of the bitfield

[arctic mesa]

Look at the instr field definition; this is primarily to complete the parity of field and instruction bit patterns.

[fleet pendant]

Ok, but I would just compeltly delete that definition

and instead write two more instructions for each of those cases

[fleet pendant]

There is no real parity, instruction's bitfields have way more features

[fleet pendant]

(this would actually reduce the linecount of your example)

[arctic mesa]

It is not practical if you have more than 1 bit as ?

read the insrt definition realy closely

[fleet pendant]

The fact that your description of your %a(instr) has multiple lines should be a warning signal to you

Just separate it into two cases

[arctic mesa]

In this case it is the more resonable solution, but if your fields look like this:

[fields]

alu_binary_op_instr
ADD 0000?0
SUB 0000?1
SHL 000100
SHR 000101
ROL 000110
ROR 000111
POPCNT 001???
AND 010001
NOT_B_THEN_A 010010
NOT_A_THEN_B 010100
XOR 010110
OR 010111
NOR 011000
XNOR 011001
A_THEN_B 011011
B_THEN_A 011101
NAND 011110
...

[fleet pendant]

Then go and redesign your ISA

Also, hopefully your instructions all have a canonical encoding

E.g. for etca, the fact that some bits are don't care is an implemention detail and the ISA itself classifies those as illegal

[shrewd matrix]

How would wildcards in fields even work? If the parser sees ADD, how would it turn that into an integer if it evaluates to 0000?0? It would have to choose something for ?, which a) is nonsensical and b) defeats the point of a wildcard?

Like in your first example, what binary would add produce?

[fleet pendant]

It would choose 0, the same as for instructions bitfield

this would only have an effect while disassembling

[arctic mesa]

Currently, Instruction bit fields parse ? as 0

[shrewd matrix]

I guess

[fleet pendant]

And IMO having bits that sometimes matter and sometimes don't in such a field is indicative of a messy ISA specification and should be fixed.

[arctic mesa]

To be honest, these are just feature suggestions; and also I ? as much about ? as the other 2 points; but I'd like that to be implemented if/when we would get a "disassembly view" feature for memory components such as any RAM or SSD (like I've written in the comments of the proposed syntax spec.isa).

[fleet pendant]

Just to be sure: You are aware that ? is already implemented in instruction bitpatterns?

[arctic mesa]

Yes

but you need to write a LOT of instruction definitions that way

[fleet pendant]

If your ISA is very messily design, yes

From the ISAs I am aware of (etca, x86, ARM, RISC-V, LEG, overture, 6502) noone of them really benefit from this ability

And the only result for overture your showed is that the automatic instruction descriptions get even more messy

[arctic mesa]

Technically, there are 2 implementations in that spec.isa

The reason for it being like this, is the "hardware implementation" inside which this layout is more optimal, because it requires less decoding logic (like inversions), and the *.isa needs to follow it, and while most discard certain valid bit patterns, I would prefer not to, as I don't need to keep track of/check this myself every time I'm thinking on extending the architecture that way.

Because the LEG arch (essentialy) has no decode logic to speak of

[fleet pendant]

Ok, let me repharse my objection: If adding this features encourages you to create isa specs like the one you wrote for overture at the top, it's a bad feature

That ISA spec fails to produce good descriptions of instructions automatically specifically because you are using fields too much

[arctic mesa]

Then look at the standard OVERTURE spec.isa; it isn't that much different when it comes to comments for ALU or jump instructions, and the rest were coppied from it

[fleet pendant]

And here as well POPCNT: is a unary instruction, so it should be a disinct description

[arctic mesa]

like this one: OR r1 and r2 and store the result in r3.

[fleet pendant]

That doesn't contain the problematic sentence part "If it is an ALU instruction"

[arctic mesa]

POPCNT in that implementation is 16 bits wide, and it takes BOTH arguments as inputs

[fleet pendant]

Aha interesting, I wouldn't have guessed that

Another argument for writing an explict description

[arctic mesa]

Let me rephrase, it is essentialy: POPCNT(A)+POPCNT(B) where A or B are 8 bit and can be an immediate (this is a modified LEG arch)

Besides, making it a unary instructionis wasteful (in that architecture)

[arctic mesa]

Well I guess I could have added the comments to the field definitions, by adding // comments after each bit representation of a field, like this:

[fields]

alu_binary_op_instr
ADD          0000?0 // Add both operands together
SUB          0000?1 // Subtract the first operand from the second operand
SHL          000100 // Shift the first operand to the left by the second operand
SHR          000101 // Shift the first operand to the right by the second operand
ROL          000110 // Rotate the first operand to the left by the second operand
ROR          000111 // Rotate the first operand to the right by the second operand
POPCNT       001??? // Count the number of [1] bits in both operands
AND          010001 // And both operands together
NOT_B_THEN_A 010010 // !(B => A) both operands together
NOT_A_THEN_B 010100 // !(A => B) both operands together
XOR          010110 // Xor both operands together
OR           010111 // Or both operands together
NOR          011000 // Nor both operands together
XNOR         011001 // Xnor both operands together
A_THEN_B     011011 // A => B both operands together
B_THEN_A     011101 // B => A both operands together
NAND         011110 // Nand both operands together
...

Also I forgot to add (what seems like an oversight problem) a suggestion to the list of improvements.

[fleet pendant]

I think you are missing a word? Otherwise I have no idea what you are trying to say

[arctic mesa]

I added it to the top

[fleet pendant]

Aha, so a duplicate of https://discord.com/channels/828292123936948244/1273233354266902619

[arctic mesa]

I guess, I had already commented it there too; I will remove it then

[arctic mesa]

@fleet pendant so this is not good enough?

[fleet pendant]

You are missing my point

[arctic mesa]

Well I'm trying to reduce the repetition (in this case due to required individual definitions of instructions, that have not right to have different bit patterns other than the instruction code itself) in spec.isa files as much as possible, and that is the result

Fine, I can let go of don't care support inside of fields.
@fleet pendant , can I delete this thread and make a new one without the request for them?
Because, 99.99% of this thread is just our argument about that.

[fleet pendant]

Which is why it's generally a good idea to make multiple threads for different ideas anyway

Just change this one ot be about the support for don't cares in field bit patterns

And honestly I am not fully rejecting it

I still think it's useless for 99% of well designed ISAs and CPU implementations

But your example does show that people will use fields even when it means that the automatic descriptions will get a lot worse, and we should probably accommodated for that somehow

[arctic mesa]

I guess that makes sense. Still though if we ever get that "dissasembly view", this might make a lot more more sense.

[arctic mesa]

Then we would need to add proper descriptions to the fields themselves

[fleet pendant]

I disagree since this should only be relevant for viewing non-code or badly assembled code.

[arctic mesa]

Allow to use ? as don't care in [fields] keyword bit patterns of "spec.isa"