On 5/7/12 12:12 PM, Will Coleda wrote:
On Mon, May 7, 2012 at 10:34 AM, Adam Russell<[email protected]> wrote:
On 5/5/12 7:53 AM, Will Coleda wrote:
We've been saying for years now that users shouldn't use PASM, but PIR
(and lately, a push to NQP or winxed instead of PIR). Are any of our
users currently using PASM?
Moritz, JimmyZ, Whiteknight, and I are investigating what a parrot
without PASM looks like in the coke/rm_pasm branch.
So far for this branch:
* parrot will no longer try to parse foo.pasm as a PASM file.
* t/ tests that happen to use PASM are being rewritten in PIR
* t/ tests that test PASM itself are being dropped
* generated constant files are now PIR instead of PASM - drop in
replacement except for s/.pasm/.pir/
* some doc updates
Still to come:
* more work to be done updating t/
* more doc updates
* convert/drop any remaining .pasm files
* remove PASM compiler from IMCC
But PASM opcodes will remain valid in PIR, right?
opcodes are opcodes, yes. PIR gives you a lot of syntactic sugar over
PASM, but you can still use straight opcodes.
Some changes that came up a lot doing test conversions in branch:
.pcc directives don't exist in PIR. You have to use ".sub".
PASM-style direct register access (P4, S2) doesn't work in PIR. you
need "virtual' register access ($P4, $S2).
don't need "end" at the end of a block of PIR. (since everything is in a .sub)
.macro_const works fine in PIR.
Well that is fine and all I suppose. I perhaps alarmed myself into
thinking this was a wider change than it really is.
For my purposes (as a user (as was asked)) I actually prefer
to *not* take advantage of much of PIR's syntactic sugar. As long as
unadorned PIR works I really don't care. ;)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
