Bug 579 - c/c++ macros for inline assembly supporting svp64
Summary: c/c++ macros for inline assembly supporting svp64
Status: IN_PROGRESS
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Jacob Lifshay
URL:
Depends on:
Blocks: 577
  Show dependency treegraph
 
Reported: 2021-01-22 23:31 GMT by Luke Kenneth Casson Leighton
Modified: 2022-06-24 10:38 BST (History)
2 users (show)

See Also:
NLnet milestone: NLNet.2019.10.032.Formal
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2021-01-22 23:31:02 GMT
c macros and c++ inline classes are needed which allow for svp64 inline assembly to be created without (initially) modifications to gcc or binutils.

initial scope is to restrict incoming and outgoing registers from inline register-to-variable parameters to r0-r31 / fp0-fp31

"internal" assembler known as "basic" asm is not so restricted.
Comment 1 Jacob Lifshay 2021-01-22 23:43:20 GMT
we might want to split this into two parts, SV support for unmodified gcc/binutils, and SV support once enough has been added to gcc to support full length vectors as inline asm arguments.

Also, what's the list of ops we actually need for this task to be considered complete?
my initial list:
unsigned/signed 8/16/32/64-bit vectors and pointer vectors:
add
sub
mul
muladd
div
rem
and
or
xor
not
neg
splat
unit-stride load/store
gather-scatter load/store
typecast

f32/f64 vectors:
add
sub
mul
div
sqrt
fma
neg
abs
splat
unit-stride load/store
gather-scatter load/store
typecast
Comment 2 Jacob Lifshay 2021-01-25 07:07:14 GMT
Started working on this, code at:
https://salsa.debian.org/Kazan-team/simplev-cpp

I just wrote a simple testing framework for now
Comment 3 Luke Kenneth Casson Leighton 2021-01-25 11:27:52 GMT
(In reply to Jacob Lifshay from comment #1)

> we might want to split this into two parts, SV support for unmodified
> gcc/binutils, and SV support once enough has been added to gcc to support
> full length vectors as inline asm arguments.

good idea.  let's leave this one as SV support for unmodified gcc/binutils,
it's what we need right now, as quickly as possible.
 
> Also, what's the list of ops we actually need for this task to be considered
> complete?

it should be auto-generated from the python parsing code called "pagereader.py"
and the CSV file reading.  therefore the answer is "what we have in the
wiki: the CSV files and the pseudocode pages".

that list - the pseudocode - is what's been added to ISACaller - because it's
literally executed after translation to python - and the TestIssuer pipelines
were created afterwards.


example code on how to do this is here:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/sv/trans/svp64.py;hb=HEAD

pagereader.py obtains the instruction-argument format (ISA class),
the new SVP64RM class obtains the SVP64 EXTRA2/3 information, you can
see how it's processed.


if you are attempting this by hand it is completely the wrong approach
that will create a huge maintenance burden in the future.

*do not* hand-create the macros: auto-generate them from python.

we do *NOT* want to have to update these macros by hand every single time a bug
is found or a new instruction added.

also please don't create bash scripts to do the same job, or duplicate the python
code, or create rust code, or create c++ code to do the exact same job as
the existing pagereader.py


for now, then, because there is no FP pseudocode there are no FP operations
added.  this will have to be done later as a separate task.
Comment 4 Luke Kenneth Casson Leighton 2021-01-25 11:49:35 GMT
(In reply to Jacob Lifshay from comment #2)
> Started working on this, code at:
> https://salsa.debian.org/Kazan-team/simplev-cpp
> 
> I just wrote a simple testing framework for now

the projectpreference is for using git.libre-soc.org - remember you only have
to ask https://git.libre-soc.org/?p=simplev-cpp.git;a=summary

feel free to help to turn svp64.py parsing into parameterised functions
(i will make a start this morning before you're up, US time).  both you,
alexandre, and other people in the future will need it to do the
auto-generation of svp64 "field interpretation", particularly the
EXTRA2/3 fields.

it's rather unfortunate that there's not enough bits free in the 24-bit RM
extra to actually say what format the EXTRA2/3 fields are, meaning it has
to be obtained by looking at what the actual opcode is.

at some point PowerDecoder will have to do the same trick.
Comment 5 Jacob Lifshay 2021-01-25 23:42:24 GMT
(In reply to Luke Kenneth Casson Leighton from comment #3)
> (In reply to Jacob Lifshay from comment #1)
> 
> > we might want to split this into two parts, SV support for unmodified
> > gcc/binutils, and SV support once enough has been added to gcc to support
> > full length vectors as inline asm arguments.
> 
> good idea.  let's leave this one as SV support for unmodified gcc/binutils,
> it's what we need right now, as quickly as possible.
>  
> > Also, what's the list of ops we actually need for this task to be considered
> > complete?
> 
> it should be auto-generated from the python parsing code called
> "pagereader.py"
> and the CSV file reading.  therefore the answer is "what we have in the
> wiki: the CSV files and the pseudocode pages".

I think that's totally the wrong approach, it will take much more work to write a code generator than to just write the C/C++ code for the few instructions we actually need right now.

I'm going to start writing it by hand, I think you may be surprised at the relatively low amount of code needed.

> 
> if you are attempting this by hand it is completely the wrong approach
> that will create a huge maintenance burden in the future.

Not really, since we'll just be throwing this code out once the instructions are implemented in gcc.


> for now, then, because there is no FP pseudocode there are no FP operations
> added.  this will have to be done later as a separate task.

Ok, though it isn't that hard to add FP.
Comment 6 Jacob Lifshay 2021-01-25 23:57:38 GMT
(In reply to Luke Kenneth Casson Leighton from comment #4)
> (In reply to Jacob Lifshay from comment #2)
> > Started working on this, code at:
> > https://salsa.debian.org/Kazan-team/simplev-cpp
> > 
> > I just wrote a simple testing framework for now
> 
> the projectpreference is for using git.libre-soc.org - remember you only have
> to ask https://git.libre-soc.org/?p=simplev-cpp.git;a=summary

I had code to push while you were asleep and I don't have access to easily create repos on git.libre-soc.org, whereas it takes me like 20s to create a new repo on debian salsa.
Comment 7 Luke Kenneth Casson Leighton 2021-01-26 00:41:29 GMT
once it's written by hand it can be analysed for autogeneration.

this is important jacob.

there is always a cost to doing autogenerators that is worthwhile to ensure transcription errors do not occur and to eliminate review and maintenance costs.

i have been through this evaluation process many times.
Comment 8 Luke Kenneth Casson Leighton 2021-01-26 01:27:34 GMT
i appreciate that the first step is to fo some of the macros by hand, in order to begin to recognise the patterns.

once the process of laboriously hand-crafting the macros has begun it will quickly become apparent that continuing to hand-craft them is monotonous and likely to be error-prone.

and, also, laborious and a significant burden when extending them.

however at the early phase it is often *not possible* in advance to know what the patterns are.

so please, yes go ahead with hand-crafting but the moment the thought occurs to you that you are repeating things cut/paste laboriously *please stop* and transfer over to an autogenerated approach.

this is crucial because we may need to make adjustments and if that involves making 150 to 300 adjustments to *hand-crafted* code we have just painted ourselves into a corner and wasted an awful lot of time
Comment 9 Jacob Lifshay 2021-01-26 03:09:41 GMT
Well, I ran into an issue, we need to decide what extended opcode to use for setvl.

Basically can't get any working code till then.
Comment 10 Jacob Lifshay 2021-01-26 03:35:47 GMT
Pushed WIP code implementing sv_setvl to https://git.libre-soc.org/?p=simplev-cpp.git;a=summary
Comment 11 Luke Kenneth Casson Leighton 2021-01-26 03:40:49 GMT
spec says ext022 is reserved for experimentation.
Comment 12 Jacob Lifshay 2021-01-26 03:43:03 GMT
(In reply to Luke Kenneth Casson Leighton from comment #11)
> spec says ext022 is reserved for experimentation.

well, according to https://libre-soc.org/openpower/sv/setvl/
we already picked 19 as the primary opcode but didn't pick an extended opcode
Comment 13 Luke Kenneth Casson Leighton 2021-01-26 04:19:27 GMT
i put 19 because it makes sense to design it where it would most sensibly fit (if approved)
this is not permitted however in silicon and we are required to use the sandbox major op.
Comment 14 Jacob Lifshay 2021-01-26 04:22:15 GMT
(In reply to Luke Kenneth Casson Leighton from comment #13)
> i put 19 because it makes sense to design it where it would most sensibly
> fit (if approved)
> this is not permitted however in silicon and we are required to use the
> sandbox major op.

well, if we're going that route, all of svp64 is not permitted since there is no 64-bit sandbox.
Comment 15 Luke Kenneth Casson Leighton 2021-01-26 11:15:34 GMT
(In reply to Jacob Lifshay from comment #14)
> (In reply to Luke Kenneth Casson Leighton from comment #13)
> > i put 19 because it makes sense to design it where it would most sensibly
> > fit (if approved)
> > this is not permitted however in silicon and we are required to use the
> > sandbox major op.
> 
> well, if we're going that route, all of svp64 is not permitted since there
> is no 64-bit sandbox.

i know.  that's why, on every single call when speaking to someone related to the OPF i gently remind them of the urgency of getting proper permission to do so, and that it's missig from the spec. (you may have noticed i do that?)

however Mendy explained it to me in an hour-long conversation a couple months back: there exists a "safety-valve" here: as long as we do not go to mass-volume silicon with an "unauthorized" ASIC that, if it is "wrong" or disruptive in some way, then IBM simply doesn't have any "financial or other harm caused to their business" with which to even stand up in court and consequently a case that they hypothetically brought would be thrown out.

therefore as long as we keep to test ASICs, simulations, FPGAs and don't sell large quantities, we're fine.  i say "fine", i mean "still dependent on OPF ISA WG for approving a massive amount of work we're doing".  sigh :)