Assembly semantics

[mcosta]

Hi,

I would like to know if is there any documentation that explains in detail the VEX assembly semantics and the binary of each instruction generated by the compiler (if that exists, I'm not sure how it works in a simulation).

I'm working on an assembler targeted at a VHDL VEX implementation (the r-VEX project, at TUDelft), and there are some points that are not entirely clear for me. For example:

- The MOV instruction works for register to register and for immediate to register. If the assembly instruction is the same (i.e., there is no MOV and MOVI), then, what should be the binary generated?
- What the instruction MTB is supposed to do? Just tranfer the least significant bit of a GR to a BR register? For what is it for?
- What happens in function or recursive calls? Is there something in the assembly code that tells the simulator to do somenthing?

Thank you.

Maurício Costa

[frb]

The book is a good place to start...

Mnemonics and implementation are two different things - a move is a move regardless of what it moves to/from (as long as all bits are preserved). In your encoding design you'll probably have to make a distinction between an immediate and register operand, but there are several ways of doing that (not necessarily in the opcode).

MTB/MFB are used primarily to spill and restore branch registers when needed (across calls when caller-saves, when running out of branch registers)

Recursion? That's handled by the compiler as usual - I don't see any fundamental difference between VEX vs. other instruction sets

-- Paolo

[rseedorf]

Dear paolo,

regarding the pseudo operations which the ASM assembler should recognize can you sent me a list like that off table A.1
of the book which explains what type of registers can be the target and source for certain pseudo operation. For example
for MTB/MFB can these directly write to/from memory (stack) or should this be done via an GR register. The list should
include the following pseudo operations (mnemonics):

1. SBIT
2. TBIT
3. MTB
4. MFB
5. MFL
6. MTL

pseudo operation | operation | description
MFL STW im[s1] = s2 Store word

I have looked for this information in the documentation of the tool chain of the ASM assembler,
the book and the online documentation, without any success. Also what does the assembler has to do
when parsing the ".trace" directive

Kind regards CE graduate student from TU Delft,
Roël Seedorf

[frb]

Except for MFB/MTB (move from/to branch register) I'm not sure any of the other opcodes in your list are ever generated. Can you send an example where you see them? By the way only load/store operations access memory in VEX.
Many of the other assembler annotations (like .trace) could be safely ignored (may be useful for debugging, but I'm assuming you're not writing a debugger, are you?)

In general, if you're serious about using VEX to generate binaries, you should consider porting GNU's binutils and the associated tools (gas, gld, etc.). A good starting point would be the STLinux distribution (look for the cross-compilation toolchain at http://www.stlinux.com for the ST2xx family). The reason for this is that the ST2xx assembler is a close relative to the VEX assembler, so you may save yourself some time by bootstrapping off the distribution ST provides.

Good luck,

-- Paolo

[rseedorf]

Dear paolo,

the list of pseudo operations can be found in the directory: vex-3.41/share/asm/vexopc.h On line 142 there
is a list of move operations. Also see line 132-133. Since these operations are defined in the compiler but are
not part of the VEX operations as defined in the book, I assumed that they are pseudo-operations. So if my
assumption is correct what can the target and source operands be when using native VEX operations ?

Currently I am working on an assembler which directly generates a .vhd rom file. For a designed 5-stage pipelined
reconfigurable VEX processors. But as the application that has to run needs a linker/loader I am investigating ways
to include these in available toolchain.

Kind regards Roël

[frb]

I see, these are heritage of some older VEX version, but I doubt the compiler generates it. I believe they are
SBIT t = s, im ## Set bit <im> in register <s> and assign result to <t>
TBIT t = s, im ## Test bit <im> in register <s> and assign 1 to <t> if true else 0 (t can be gr or br)
They are somewhat redundant because they can be generated with and and or operations (and a long immediate)

MFL t = <link register>
MTL <link register> = s
These are copy operations to/from the link registers

Hope this helps.

-- Paolo

[rseedorf]

Dear paolo,

It seems that I have discovered a bug in the vex compiler.When targeting code for a pipelined vex processor without forwarding it seems that the compiler forgets the dependency between the stack pointer and spilling the return address register, with respect to this register. Although this snipset of code will run correct on a machine with forwarding like the ST200, when executing it on an implementation of vex processor without forwarding, problems will arise. I supply you with snip sets of the .fmm file and the .s file after pulling the generated assembly from the compiler through vexasm:

## Begin bar
.section .text
.proc
.entry caller, sp=$r0.1, rl=$l0.0, asize=-32, arg($r0.3:s32)
bar::
.trace 1
c0 add $r0.1 = $r0.1, (-0x20)
;; ## 0
.call foo, caller, arg($r0.3:s32), ret($r0.3:s32)
c0 call $l0.0 = foo ## bblock 0, line 7, raddr(foo)(P32), t1
c0 stw 0x10[$r0.1] = $l0.0 ## spill ## t2
;; ## 1
c0 ldw $l0.0 = 0x10[$r0.1] ## restore ## t2
;; ## 2
;; ## 3
;; ## 4
.return ret($r0.3:s32)
c0 return $r0.1 = $r0.1, (0x20), $l0.0 ## bblock 1, line 7, t3, ?2.1?2auto_size(I32), t2
;; ## 5
.endp

---------------------

the .fmm file:

MM_CONFIG: Me "AluR.0", delay 2
MM_CONFIG: Me "Alu.0", delay 2

Although a manual solution is easy as it involves adding 2 nops, I think this schould be fixed. Could you check this and get back to me?

Regards Roel

[frb]

The initial entry operation is not really an "Alu", but an "Entry". Try setting the entry delay, and see if it works.
You do realize that setting "Alu" delay to 2 implies that *every* ALU operation will have an extra delay cycle, do you?
-- Paolo

[rseedorf]

Dear Paolo,

from Appendix A.6.2 I understood that issue-use delay allows freedom to make the latency of an operation visible to the compiler for certain
functional units.The first operation in the .asm snipset code is an addition with an immediate (-32) on source 2. I have already tried what you
suggested before I contacted you. I Also know about this 2 cycle delay for every ALU operation. I have designed a pipelined version of the VEX .
However it will not support forwarding.

I have worked out forwarding equation and I expect the wire complexity for this to give issues for an implementation on an FPGA. Furthermore
the needed muxes are 12 X 1, this increases the logic depth in et EX0 stage by four. Since the compiler has this option I want to use it to generate
the necessary nop's.Also I was not referring to the .entry directive ("Entry"), If that was what you meant in your last mail. I was referring to the add
involving the sp ($r0.1) and the dependend stw operation. The dependency of the sp as a base address for "pushing" the stack register and the add
seems to get forgotten by the compiler. So why does the compiler not recognize this dependency ,as it would insert two nops if it did. For other
operations in the assembly file the required nop's are evident as specified in the second line off the .fmm snipset, see last email.

Okay long reply but I hope you understand the problem I am sketching.

Kind regards from me, and greetings from advisor professor Stephan Wong

[frb]

Concerning the 2-cycle delay for all ALU, I'll let you draw your own conclusions, but if you can't support forwarding, perhaps slowing cycle down may not be such a bad idea...

I understood your question about the entry delay. It is indeed scheduled on a separate unit, called "ENTRY", that happens to also issue an ALU operation. Something similar happens to the RETURN operation, for example. The ENTRY unit has its own latency, which is independent of the IA (integer ALU) latency. If you dump the IL2 or IL3 intermediate ops, you'll see what I mean (try -mP3OPT or -mP2OPT and the compiler will tell you the list of all the P2 and P3 options, I don't recall the exact option off the top of my head, it's -mP3OPT_show<something>).

The bad news is that I don't believe the .mm file allows to change the special units. The good news is that I think you can write an assembler filter to add an extra empty cycle after any instruction marked with ".entry" relatively easily. There's a simple example how to inject a filter in the distribution.

-- Paolo