[Libre-soc-isa] [Bug 1048] OPF ISA External RFC ls011 - Fixed and Floating point LD/ST-with-update EXT2xx instructions

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1048

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djac at calderwoodhan.com,
                   |                            |james.lewis at redsemiconducto
                   |                            |r.com

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Andrey Miroshnikov from comment #23)
> Luke, I added inline imports for:
> fixedload, fixedstore, fpload, fpstore, pifixedload, pifixedstore
> 
> https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;
> h=1b25b0de237d38e761faf5d7716d0a8f3313f8f8

fanntastic. it comes out really well at the wiki page, already.
hmmm should probably put some \section breaks in it somehow,
or to the python "rewriter" program at least add an extra "#"
in front of the sections.

let me deal with that, the inline "hook" into 

https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/pandoc_img.py;hb=HEAD

> I noticed that some instruction entries already present in ls011.mdwn have
> an additional table for the instruction form.

yeees. ok right, those are there for if the "Form" does not... hang on
let me check what you are referring to... do you mean this:

 202 ```
 203     |0     |6   |9  |10 |11   |16      |31 |
 204     | PO   |    RT      |   RA|   D        |
 205 ```

because 

> See for example lwzup, which has an D-Form table:
> https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls011.
> mdwn;h=9137b5d2778d420e53b79c31397ad10ed447b5ee;
> hb=1b25b0de237d38e761faf5d7716d0a8f3313f8f8#l377

yes you do mean that.

 372 ```
 373     |0     |6   |9  |10 |11   |16      |31 |
 374     | PO   |    RT      |   RA|   D        |
 375 ```

ok so this is *required* for the submission on what i call
"radio button 3" RFC submissions, as it s R-B-3 that will
*actually* go into the *actual* Power ISA spec.

therefore for *RB3* they need *exactly* the same format as if you were
going to go "cut/paste" from RFC into Power Spec document.

this especially matters when we do entirely new instructions.
but this here, what we are doing, is:

1. *not* submitting new fields (see ls004 which *does*, it adds
   Z23-Form and a new SH field)
2. *not* submitting R-B-3 we are submitting Radio-Button *TWO*
   which is simply "hey ISA WG can you please give us some general
   feedback on the *idea* of what we will *later* submit for actual
   inclusion in the Power ISA Spec"

so i am not hugely concerned if the R-B-2 submission is not exactly
to the letter identical to an R-B-3 submission.

> While the inline import doesn't have the D-Form table:
> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/
> pifixedload.mdwn;h=0418b1cd4e89ec350842d373190343fcd1c72893;hb=HEAD#l171

sigh i know. ultimately the idea is to put those in by using
Dimitry's insndb system and my pagereader.py (which reads all
instructions) plugged directly into a pandoc filter:

https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/Makefile;hb=HEAD

  26 %.pdf: tex_out/%.mdwn ../../pandoc_img.py
  27         pandoc \
  28                 --pdf-engine=xelatex \
  29             -V 'mainfont:DejaVuSerif' \
  30             -V 'sansfont:DejaVuSans' \
  31             -V 'monofont:DejaVuSansMono' \
  32             -V 'mathfont:Latin Modern Math' \
  33                 --filter ../../pandoc_img.py \  <- add another one

basically rather than have this:
 690 [[!inline pages="openpower/isa/fixedload" raw=yes ]]

instead we have say...
 690 <!- include-instructions(fixedload.mdwn) -->

and the (TBD) pandoc filter program goes "ah HA! let me just call the
insndb system and spew out a bunch of instructions in exactly
Raio-Button-3 format"

see how that works and is a ridiculously small amount of work for
a massively effective end-result, which has the added side-bonus of
*not* having us screw up by having two sets of identical instructions
to maintain, *and* saves a vast amount of effort across *fifteen*
RFCs?

> Do the duplicate entries in ls011.mdwn need to be removed (since the inline
> files replace them)?

basically yes, they go.  i only had them as placeholders to show the
principle, maintained the summary table so as not to forget but also
to have some idea of number of instructions.

but the idea of literally cut/pasting 100s of instructions inline
into the RFCs then hand-adding the "Form" (opcode bits/names) is
an incredibly stupid one that should have been dealt with by doing
a program that autogenerates what is {inline-included}, a frickin
long time ago!

but the rush to get RFCs in as been so intense that it just hasn't
happened yet.

it is what it is :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.