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 <[email protected]> wrote: > 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
