[Oberon] Re (2): Documentation;

[Joerg]

Peter

>> V is one of the modifier bits of instructions with format
>> F1:  01uv a b op im
>>        4  4 4  4 16
>> So it's bit 28.
> 
> Bit 28 counting from the right.  (Why not 3 from the left?)

This is just convention. If you type cast the instruction into a SET, you can check for the value of v by     IF 28 IN instr THEN ...


> Would this wording be better?
> "When bit v is 1, im is extended with an additional 16 bits. Thereby 
> allowing im a total of 32 bits."
> 
> Where are the additional 16 bits?

The RISC5 internal registers are always 32 bits wide.
If you look at format F1, you see the constant value „im“ in the instruction is only 16 bit wide. So when the RISC5 CPU decodes the instruction, it has to copy over „im“ into an internal 32 bit register. The CPU does this as follows: it copies over the 16 bit „im“ to the lower 16 bits of the internal register and fills the upper 16 bits with the v-value found in the instruction.
This CPU behaviour is coded in Verilog (RISC5.v) as follows:
assign C1 = q ? {{16{v}}, imm} : C0;

> I'd never guess BL = "branch and link".  In fact I searched 
> Risk-Arch.pdf and RISK.pdf and didn't find it. Can these acronyms 
> be read somewhere?  Only in lectures notes?

In the risk architecture you find the following hint: „If v = 1, the link address PC+1 is deposited in register R15.“
So when v=0 the assembler instruction is called just „B“ (for branch) followed by the condition. e.g BMI (branch if minus) or BEQ (branch if equal) and so on or just B (branch always, cond=7)

If v=1 the assembler instruction is called „BL“ (for branch and put link in R15) followed by the cond. For jumps to procedures, the compiler always sets cond=7, so the instruction mnemonic stays „BL“ as cond=7 has an empty name (see mnemonic table for Format F3). For traps, the condition might vary and the generated instruction might be BLEQ (branch and link if equal) BLMI (branch and link if minus) and so on.

> 
> RISC-Arch, page 2 has this.
> 3. Branch instruction   (Format F3)
>   | 110v | cond | 16 bits | 0000 | c |
> F3 | 111v | cond |         off        |
> 
> The branch instruction has two forms according to the value of u. 
> u is bit 29 counting from the right.

Very roughly speaking, you’re right with the two instruction codings: the RISC5 takes over the jump offset from a register (the CPU names it internally C0) or from the immediate value in the instruction. (the CPU nanes it internally disp)
The Verilog code for this looks like:
assign pcmux0 = (BR & cond) ? (u? nxpc + disp : C0[23:2]) : nxpc;
Be aware that Interupts (chapter 5 of the RISC5 architecture) use format F3 as well.
For interrupts, bits 4 and 5 of the branch instruction are not 0.

> This was cited by Andreas. 
> 
> | BL (4) | cond (4) | mno (4) | pno (8) | pc-fixorgP (12) |
> 
> Which is not conformant to either F3 until fixed up to the following.

As I tried to explain in the previous mail, what Andreas mentioned is what the compiler generates. But this is NOT a valid RISC5 instruction at all. The loader extracts the important information out of this „virtual instruction“ and completely overwrites all bits with a valid branch instruction complying to F3 coding. The RISC5 CPU described in RISC5 architecture will NEVER see Andreas‘ coding. The compiler hands over information to the loader, who later on extracts its info and overwrites it with a valid RISC5 compliant instruction.

Basically, it’s just coincidence that Andreas used F3 to encode the loader information. Bits 28 to 31 are not looked at by the loader at all and could be anything (ADD, LD, ST, DIV...whatever)
Andreas could even have decided to use a totally different coding that has nothing to do with RISC5 at all, eg.
| mno(8) | pno(8) | cond(4) | pc-fixorgP (12) |
The used 32 bit coding is an agreement between the conpiler and the loader. Not RISC5.

br
Jörg