PASM

Adam Russell ac.russell at live.com
Tue May 8 20:26:37 UTC 2012


On 5/7/12 12:12 PM, Will Coleda wrote:
> On Mon, May 7, 2012 at 10:34 AM, Adam Russell<ac.russell at live.com>  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. ;)



More information about the parrot-dev mailing list