PASM

kjstol parrotcode at gmail.com
Mon May 14 09:31:59 UTC 2012


hi there,

Was just lurking and thought to chip in here. I seem to remember that
the decision to keep PASM was grounded in the need or desire to have a
 "pure" textual representation of the byte code. PASM is much closer
to the byte code than PIR, though not 100% equal.

Having said that, it's probably a good idea to remove PASM, as it will
clean up the lexer and parser a bit; if there's going to be any
evolution of PIR allowing to write more high level stuff, then it's a
good idea to do it in such a way that it's compatible with lower-level
stuff. Let me rephrase that: it's a good idea to have 1 "language"
that allows to write both low-level and high-level constructs (e.g.,
PASM style and PIR style function calls). By removing PASM, there's 1
language, which could potentially be adjusted and improved to be a
closer equivalent to PBC. (IMHO!)

kjs

On Tue, May 8, 2012 at 9:26 PM, Adam Russell <ac.russell at live.com> wrote:
> 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. ;)
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev


More information about the parrot-dev mailing list