[Closed] lcb: Discussion on immediate fields in assembly strings

[kper]

It is possible to define machine instructions with an assembly directive. This assembly directive is used by the compiler for printing an assembly representation of an instruction.

An example would like that

  model UtypeInstr (name : Id, opcode : Bin, rhsEx : Ex) : IsaDefs = {
    instruction $name : Utype =                        // upper immediate instructions
      X(rd) := $rhsEx
    encoding $name = {opcode = $opcode}
    assembly $name = (mnemonic, " ", register(rd), ",", hex(imm))
    }

$UtypeInstr (AUIPC; 0b001'0111 ; PC + immUp)         // add upper immediate to PC
$UtypeInstr (LUI  ; 0b011'0111 ;      immUp)         // load upper immediate

Note that in the case of LUI the behavior is X(rd) := immUp. This means that the LUI instruction has two operands: rd and immUp. The assembly directive uses the both the rd which is ok since it is an operand and imm because immUp encodes imm. However, hex(imm) uses imm which is not an operand and instead refers to the binary representation of the instruction. This makes it necessary to encode immUp to imm. In this particular case, this is quite easy since field access functions and fields have a direct 1:1 relationship. But, if the encoding function requires multiple field access functions, the implementation becomes quite complicated and weird. (1) It's not clear why the assembly view and binary encoding are mixed. (2) It's not clear for the user that an encoding function is applied.
I propose to disallow the use of fields which are not operands. In this case imm would throw an error, while rd is ok.
A correct specification would be:

 assembly $name = (mnemonic, " ", register(rd), ",", hex(some_encoding_function(immUp)))

The difference is that some_encoding_function is a function which might be equal to a binary encoding function, but no necessarily. This separates both worlds assembly and binary nicely.

@AndreasKrall @benjaminkasper99

[AndreasKrall]

I believe I do not understand the problem completely. Why do we need an encoding function in the assembly printer? The assembly printer never has an encoding, it only has a decoding function.

[kper]

The assembly printer never has an encoding, it only has a decoding function.

No, it's exactly the opposite. The SelectionDag already operates on decoded values. So, not on fields but on field access functions (as immediates). So at the moment, if you want to print an operand in assembly, you have two choices: immUp or imm.

Below, you don't apply any function to the value. So, the output is something like that LUI a0,0xfffffffffffff000

assembly LUI = (mnemonic, " ", register(rd), ",", hex(immUp))

Below, you declared that you want to print the raw field value. However, when printing assembly, we have to apply the encoding function, so 0xfffffffffffff000 >> 12. Otherwise, the emitted LUI's immediate is too big.

assembly LUI = (mnemonic, " ", register(rd), ",", hex(imm))

The problem is that (1) it is not clear that we are mixing assembly and binary. I propose to disallow the usage of fields which are not operands of the instruction. (2) Your answer actually emphasis my point that it is not visible that the encoding function is applied. Lastly, if you have an encoding function which references multiple field access functions (ergo multiple operands), it's getting really complicated.

[AndreasKrall]

The assembly should have nothing to do with the Selection DAG, it has to be separated completely from the compiler (instruction selector). The compiler has work solely on the binary representation. Therefore, there exist the encoding and predicate functions for the compiler. The compiler has to work for different assembler printers with different syntaxes like reordering of destination and source registers or different representations of immediate values (e.g. unchanged or shifted). The compiler and the assembly printers have to be strictly separated and not intermingled.

[kper]

I want to note that I disagree with this approach.

The compiler has work solely on the binary representation.

I don't understand why my approach is creating a dependency between assembly printer and compiler. All I am saying is that the usable operands have to come from the instruction's behavior. The only change is that there will be no implicit encoding done in the printer.

Therefore, there exist the encoding and predicate functions for the compiler.

That remains unchanged.

The compiler has to work for different assembler printers with different syntaxes like reordering of destination and source registers or different representations of immediate values (e.g. unchanged or shifted). The compiler and the assembly printers have to be strictly separated and not intermingled.

Like I said the only thing that changes is that the assembly printing operates on the decoded values and if you want to print any other value, you have to use explicitly a function.

I don't understand where the intermingling comes from.

[benedikt-l-huber]

I try to summarize my understanding of the issue, without
proposing a definitive solution:
An operand can exist in three different representations.

1. semantics: As abstract value, as handled by the SelectionDAG.
   I.e., the value it really means.
2. assembly: As a string representation, used in the assembly program.
3. encoding: As bit pattern in the instruction word.

(Note: These names are my ad hoc suggestion.)

All representations can be converted into each other.
However in VADL, not all repesentations can be converted into each other directly.

In LLVM, the central representation is 1).
So all conversions go via the semantics representation.

Assembly printer:    semantics -> assembly
Assembly parser:     assembly  -> semantics
Compiler:            semantics -> encoding

Note there is no step encoding -> semantics
and the Assembler has to go the indirection
Assembler: assembly -> semantics -> encoding

In VADL the central representation is 3).

Instruction behavior:                encoding  -> semantics
Assembly description:                encoding  -> assembly

"field access function" is decoding: encoding -> semantics
"encode" is encoding:                semantics -> encoding

Assembly grammar:                    assembly -> encoding

So there is a mismatch between LLVM and VADL.
We do not have directly the information in VADL to go from
semantics -> assembly, as needed in LLVM's assembly printer.
This is reflected in @kper's proposal to replace VADL's assembly description
from a mapping encoding -> assembly, to a mapping semantics -> assembly.
(Note in the example, imm lives in the realm of encoding,
immUp lives in in the realm of semantics.)

This is a proposal worth contemplating. It could be more natural to specify
the assembly description in terms of semantics.
However, it would go against the established VADL convention that encoding (3) is the
central representation.

As far as I can tell, a possible solution in the LLVM assembly printer with the current
VADL assembly description would be one indirection, via the encoding.
So my proposed assembly printer works like this:
semantics -> encoding -> assembly
The first arrow is necessary for the compiler anyway,
the second arrow can be taken directly from VADL's
current assembly description. The second arrow is basically
an objdump.

However, the objection is valid, that this is a convoluted
and non standard approach for LLVM. It could cause
some unexpected problems since LLVM is not designed to work
like this.

Both representations have pros and cons.

Personally I would suggest as a first try to keep the current assembly descrption, i.e.,
encoding -> assembly and try implementing the indirect apporach in the LLVM assembly printer.
In case this fails, reevaluate @kper's suggestion to go to semantics -> assembly for the
VADL assembly description.

[kper]

ok, let's do that

However, I propose to keep the middle ground and allow both imm and immUp. The support for immUp is natural and almost no effort. That's also the current status quo.