[Libre-soc-isa] [Bug 615] talk to binutils and gcc developers about acceptable sv assembly format

[bugzilla-daemon at libre-soc.org]

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

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
just looking at binutils gnu-as tc-ppc.c
https://github.com/gitGNU/gnu_as/blob/29cc6aaccf8e8492046aa303b0282a4ee36d829c/config/tc-ppc.c#L2692

this is where the opcode parsing starts.  the syntax we came up with
(svadd/qualifiers/x/y/z operand1, operand2, ...) should be pretty easy
to implement.

step 1:

   see if the opcode starts with "sv", if so, call a function
   that parses any "/" separated SVP64 qualifiers.  these get
   inserted into the "upper" bits of insn (32-63) to be extracted
   later

   at the end, replace "/" by "\0" and move str on a bit

step 2:

   gather operands as normal
  
https://github.com/gitGNU/gnu_as/blob/29cc6aaccf8e8492046aa303b0282a4ee36d829c/config/tc-ppc.c#L2748

   the key function here seems to be ppc_optional_operand_value

   also that ppc_insert_operand seems to be where the "magic" happens
   (actually putting the operand into the required location in the
   assembly opcode).

   there exists an "override" mechanism in the powerpc_operands
   table which ppc_insert_operand can call for doing "special"
   stuff.

   this is where register_names are identified by dropping a
   structure into "ex" (type ExpressionS)
  
https://github.com/gitGNU/gnu_as/blob/29cc6aaccf8e8492046aa303b0282a4ee36d829c/config/tc-ppc.c#L2946

   therefore it should be possible to hook into "register_names"
   and either spot the suffix "v" (or ".v", or whatever) or otherwise
   extend it to support EXTRA2/3.

step 3:

   extract the upper bits (32-64), which could even have EXT01
   pre-inserted into them.

   output two assembled instructions (64 bit) rather than one
   (32 bit)

this is all actually pretty straightforward.

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