[Libre-soc-bugs] [Bug 550] binutils support needed for svp64
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Tue Sep 7 00:22:55 BST 2021
https://bugs.libre-soc.org/show_bug.cgi?id=550
--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
relevant links:
http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-August/003590.html
the only thing: it is *not* a good idea to hand-create the tables needed by
binutils. these should be *auto-generated*, teaching sv_analysis.py how to do
that.
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_analysis.py;hb=HEAD
there's nothing particularly sophisticated or clever about that program: it's
written in a bland, non-OO "Get It Done" style. it:
* reads OpenPOWER ISA v3.0B CSV files containing micro-code-style instruction
format information
(exactly like the tables in binutils)
* identifies and groups v3.0B instructions by identical register file profile
(number of Read regs, number of Write regs, number of CR regs read etc)
* assigns an SVP64 "Style" to each (Twin/Single-predicate, 2 or 3 EXTRA bits
for reg extension)
* spits out *more* CSV files with that grouping information in it, to assist in
decoding
thus rather than hand-create the SVP64 decoding information in binutils it
should be trivial to autogenerate c header files and c structs.
http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-August/003592.html
no deadlines given that i am using the python class, which has a mode where it
can do .S processing. i actually had to add gas macro recognition to get that
to work.
so there is a temporary workaround. however it will become increasingly more
of a priority particularly for Lauri who is working at assembler level for
Video/Audio CODECs, and later for compilers.
the function entrypoint is asm_process()
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=45b292b4c4c32bbff548f2bf299235633d31db6c;hb=HEAD#l1052
you can see it looks for ".set" macros of the utmost basic form, example where
this is used:
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/Makefile;h=4dd904b6ba48f3fcae3b1ab04e1b0479e460abd4;hb=HEAD#l34
and some actual assembler containing sv.xxx opcodes, which get translated by
asm_process() libe by line into ".long xxxxx; some_v3.0b_asmopcode"
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD
you've seen the spec page which contains the format?
https://libre-soc.org/openpower/sv/svp64/
it's very deliberately only describing the format, not why it is what it us, or
how to *use* that format (how to implement hardware etc i mean).
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list