I've started implementing some of the new Spin2 methods for P2 instructions, but I think we should perhaps step back and re-think some of them.
In Spin1, the methods all looked like regular Spin function calls, and if they produced a value it was returned as a result. For example, we would do things like:
x := locknew
repeat while lockset(x)
The proposed Spin2 intrinsics change this to be more like the PASM instructions:
while cf_ <> 1
I don't like the new way of doing things, and I'd like to propose that Spin2 revert to the Spin1 way. I have several objections:
(1) In the old way, it was immediately obvious to the reader (and the compiler) which variables were being changed -- none of the methods modified their parameters, and to update a variable you had to use an assignment operator ending in '='. In the Spin2 proposal that's no longer true; there's nothing to tell the user whether locknew_(x) changes x or not.
(2) It's no longer possible to chain functions together, i.e. to pass results of these intrinsic methods to other methods. This will be particularly painful for the arithmetic functions like GETRND, where the output might reasonably be passed to a user's function.
(3) Global variables like CF_ and ZF_ make reading the program harder (due to hidden state) and inhibit optimizations.
(4) It's generally not compatible with Spin1, or with other languages like C. In C, for example, if we wanted to implement the intrinsics in the same way we'd have to write something like locknew_(&x), since there is no way for a C function to change its parameter. This isn't necessarily a big change, but it will confuse people.
(5) Further to point (4), taking the address of a variable will inhibit optimizations on that variable, because it makes keeping track of the variable's state much harder for the compiler. In general a big part of the work of an optimizing compiler is finding where variables change. That's easier if the variables are only modified by assignment statements.
My overall feeling is that making Spin2 look more like PASM2 kind of defeats the purpose of having a high level language. PASM2 is a very elegant assembly language, and plenty of users will want to write in it -- that's fine. For that matter, I think the "official" Spin2 compiler will probably support inline assembly, so I really don't think we need to implement intrinsics that look just like the PASM2 instructions. I think they should instead fit more comfortably in the high level language.