all of these are broken down into *one* micro-op: add.

it might be worthwhile writing a generator from the CSV files to create the different variants, of which there are a *lot*.

currently blocked on my not having access to a POWER9 computer to test, due to talos1.libre-soc.org being offline

(In reply to Jacob Lifshay from comment #2)
> currently blocked on my not having access to a POWER9 computer to test, due
> to talos1.libre-soc.org being offline

it had switched itself off.  org.open_power.Proc.FSI.Error.MasterDetectionFailure
no idea.  simply powered it back on.

add* and subf* are added and working on master.

I'm currently refactoring to support carry flag inputs and outputs, it doesn't yet compile, so my latest changes are pushed to the add-carry-wip branch

the usual way is 66 bit add.  bit hard to do on 64 bit hw :)

(In reply to Luke Kenneth Casson Leighton from comment #5)
> the usual way is 66 bit add.  bit hard to do on 64 bit hw :)

I have no issues with the actual arithmetic operations, it's the copying inputs and outputs to/from python and assembly language that is complicated, since I'm using Rust macros to generate a lot of the boilerplate and those assumed that all inputs are 64-bit registers.

(wrong bugreport, deleted)

I'm working on switching from a macro_rules-based macro for generating the inline assembly and other functions for each instruction to a procedural macro, since it's gotten to the point where rewriting it in normal rust is easier than adding new functionality to the pile of pattern-matching macros I had before.

https://salsa.debian.org/Kazan-team/power-instruction-analyzer/-/tree/e828d2acecc25a82d5c29b765163a10993547566

Note that you will probably have to run `rustup upgrade` if you run into compile errors since I'm using some features from a very recent version of rustc.

I finished adding all add-style instructions without immediate operands:
add[o][.]
subf[o][.]
addc[o][.]
subfc[o][.]
adde[o][.]
subfe[o][.]
addme[o][.]
subfme[o][.]
addze[o][.]
subfze[o][.]
addex -- only valid immediate is 0 so I included it
neg[o][.]

addex was *extra* fun to implement since the version of LLVM used in Rust doesn't even support that instruction, so I had to write lots of workarounds.

Adding instructions with immediates is waay more work because the only realistic option to support all immediate values is to JIT compile the instruction once the immediate is known. If we decide that we want to do that, it should be a separate bug report.