Architecture 1.3 updates

[stffrdhrn]

As per mail chain, I am starting to make the architecture updates to the document. (some already committed to this repo).

Changes made:

or1k 1.3 updates

TODO

• P14 https://openrisc.io/proposals/orfpx64a32 - 64-bit fpu implemented in marocchino (gcc/bintuils patches under review)

DONE

• P6 https://openrisc.io/proposals/lfmadd - clarification on internal rounding (possibly exclude new madd instructions)
• P9 https://openrisc.io/proposals/ladrp - New instruction for PIC code (already in binutils)
• P11 https://openrisc.io/proposals/lfsf - add support for 'unordered' compares
• P13 https://openrisc.io/proposals/corrections - various corrections (possibly exclude correction for l.ext* being mandatory as its not implemented everywhere)
• Floating Exception Write back
• NaN Boxing
• l.lf - new instruction discussed in mail chain, for NaN boxing completeness
• cust1 - instruction to table
• P7 https://openrisc.io/proposals/lstod-ldtos - convert between double and float
• FTOI rounding
• Updated machine instruction table (Section 18), removed page column, added Class and Opcode for quick reference

INTERNAL

• updating page format to not use MASTER PAGE per instruction, just MASTER PAGE
  per class.

[bandvig]

1. 32-bit implementation of l.adrp need clarification. Expression exts(Immediate << 13) produces 34 bit result while (IstAddr & -8192) is 32-bit. Should it be
   rD[31:0] ← (Immediate[18:0] << 13) + (IstAddr & -8192)
   (i.e. Immediate is 19-bit effective width for 32-bit machine)? Or somehow else?
2. FTOI toward zero rounding is declared for lf.ftoi.d (double precision) only. Same declaration should be added into lf.ftoi.s (single precision) description.
3. Exceptions produced by FP-comparisons (they are inherited from Rudolf Usselmann implementation and quite close to IEEE-754). It would be useful to add them into FP-comparison instruction description:
   3a) Any FP-comparison rises INF-flag if rA or rB is infinity.
   3b) lf.sfeq.s(d) and lf.sfne.s(d) (ordered) produce INV-exception if rA or rB is signaling NaN. While all other ordered comparisons rise INV-exception if rA or rB is any kind of NaN.
4. ORFPX64A32.
   4a) I see you added description for rA2 and rB2 computation into 32-bit Format subsections of each FP64 comparison instruction page as initial step. As a result, such pages look overloaded. I would propose to move rX2 computation description into an appendix (at the end of 5.4 chapter for example) and use links to it.
   4b) Combining order {rX2,rX1} looks incorrectly in 32-bit Implementation subsections. It should be {rX1,rX2}. Btw, when you submitted binutils/gcc patches your description had got correct order: {rX1,rX2}. First, your GCC port uses {rX1,rX2} order. Second, such order is definitely correct for big-endian machine: most significant part occupies register with smaller address (rX1).
5. Opposite to Rth's P13, I would prefer to left lf.ftoi.s and lf.itof.s 64-bit implementation as is. They should operate with effectively 32-bit operands and destinations. A 64-bit code loads signed 32-bit integer into 64-bit GPR with l.lws, therefore no extra sign extension required for following either lf.itof.s or l.sf*. Your clarification for 64-bit implementation of lf.ftoi.s looks good
   rD[63:0] ← exts(ftoi(rA[31:0]))
   And for consistency 64-bit implementation of lf.itof.s should be:
   rD[31:0] ← itof(rA[31:0])
   rD[63:32] ← 0xFFFFFFF

[bandvig]

An update for 64-bit implementation of lf.ftoi.s. For me more accurate would be:
rD[31:0] ← ftoi(rA[31:0])
rD[63:32] ← rD[31]

[stffrdhrn]

Thanks for the comments. I agree on adding the orfp64a32 implementations into an appendix. That is was one of the main things I wanted feedback on and it's why I didn't make that change to all instructions.

I'll make updates as per your suggestions.

[stffrdhrn]

@bandvig I have made the updates. but sorry, I accidentally pushed the changes which caused the PR to close. Can you still review?

[bandvig]

@stffrdhrn Sure, Stafford. During the next several days.

[bandvig]

Looks better.
Misprints:

1. in exception descriptions for floating comparisons: signalling → signaling
2. in chapter 5.5 ORFPX64A32
   2a) {rA1[31:0],rA2[31:]} → {rA1[31:0],rA2[31:0]}
   2b)Single-Precision to Double-Precision used for both stod and dtos :)
3. Still incorrect – {rX2,rX1} - ordering in lf.sf*u*.d while it is correct in chapter 5.5 ORFPX64A32
4. Still no description of 32-bit Implementation for FP double-precision instructions other than lf.sf*u*.d.

If you have no any objection I would like to contribute to the spec. At the same time to avoid double jobs, would you pass me “baton” for next updates to the spec?

[stffrdhrn]

Please go ahead.

…

On Sat, May 25, 2019, 8:04 PM Andrey Bacherov ***@***.***> wrote: Looks better. Misprints: 1. in exception descriptions for floating comparisons: signalling → signaling 2. in chapter 5.5 ORFPX64A32 2a) {rA1[31:0],rA2[31:]} → {rA1[31:0],rA2[31:0]} 2b)Single-Precision to Double-Precision used for both stod and dtos :) 3. Still incorrect – {rX2,rX1} - ordering in lf.sf*u*.d while it is correct in chapter 5.5 ORFPX64A32 4. Still no description of 32-bit Implementation for FP double-precision instructions other than lf.sf*u*.d. If you have no any objection I would like to contribute to the spec. At the same time to avoid double jobs, would you pass me “baton” for next updates to the spec? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AASK7H2ZRHHMNR2G6VLD7OTPXEMLPA5CNFSM4HNQMHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHPOYI#issuecomment-495908705>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASK7HY2H36GS24G5KZZYGTPXEMLPANCNFSM4HNQMHEA> .