PASM

[Andrew Whitworth]

it's good to hear from you, kjs!

Yes, the desire to keep PASM for so long was fueled by a desire to
have a textual represetation with a 1:1 relationship with bytecode.
However, as PIR became more and more complex and started relying on
things like directives to change interpreter behavior and as new
syntaxes were added to PIR that don't have any display equivalent in
PASM, this requirement made less sense. Plus, it never really served
it's purpose well enough. When you start generating complicated
constants with :immediate subs, you lose the ability to do round-trip
disassembly/reassembly anyway.

The most important motivator here is that we really don't want to keep
PASM as a valid input format, even if we do generate something
PASM-like as an output format of some tools (pbc_disassemble,
pbc_dump, parrot -E, etc). We don't want to have to talk about PASM in
the docs, we don't want anybody to write anything in PASM by hand, and
we don't want people to think that PASM is a valid or useful input
tool for Parrot. Getting rid of it helps clean up the code as you
mention, and helps reduce these other burdens.

--Andrew Whitworth


On Mon, May 14, 2012 at 5:31 AM, kjstol <parrotcode at gmail.com> wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev