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.
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
Started working on this, code at: https://salsa.debian.org/Kazan-team/simplev-cpp I just wrote a simple testing framework for now
(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.
(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.
(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.
(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.
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.
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
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.
Pushed WIP code implementing sv_setvl to https://git.libre-soc.org/?p=simplev-cpp.git;a=summary
spec says ext022 is reserved for experimentation.
(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
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.
(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.
(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 :)