WP34S Symbolic preprocessor online

[Neil Hamilton (Ottawa)]

Hi Y'All,

Based on a spec mostly worked out by Pauli, we have cobbled together an interesting addition to the WP 34S assembler tool chain. This is an assembler preprocessor (PP) that currently has the following features:

- It releases the user from the scourge of having to write those darn BACK and SKIP instruction (no more counting!). Just use "JMP SomeLabel" in place of BACK, SKIP, and GTO. Let the tool figure it all out for you.

- You can now use 'soft' labels with any instruction that would take a numeric or single-letter label, such as "XEQ DoThisReallyCoolThing" rather than "XEQ 25" (what's up with that?). Obviously there is a matching symbolic label at the target end of this as well.

- You can now use double quoted strings directly in the source and the tools will figure out that "WP 34S rocks!" needs to get parsed into 4 triple [alpha]'xxx' and a single [alpha] X.*** (Note that there a still a few known bugs in this feature if you decide to use any characters that mean something to regex. Working on it...)

*** Note that this specific example will overrun the alpha window on the screen so perhaps it is not such a good one to try :->

There are at least 3 sample programs in the library as example source for this tool. They are all knockoffs of the originals, suitably modified to take advantage of most of the features above (there is no 'promotion' of JMP to GTO in the example set -- though if you are sharp you may be able to figure out how to force it to occur).

- vector_pp.wp34s

- WHO_pp.wp34s

- 8queens_pp.wp34s

There is a new Assembler document (WP34s_Assembler_Disassembler.pdf, v0.5) that describes much of this in pretty reasonable detail (see Section 8), but basically to assemble any program that has PP code you need to add a new command line switch (-pp):

$ wp34s_asm.pl -pp vectors_pp.wp34s 8queens_pp.wp34s WHO_pp.wp34s -o wp34s-4.dat

If you don't want to use the new features, just don't use the '-pp' switch. Everything should still work as it did before. However if you feed it PP source without the '-pp' switch...

There are definite restrictions for using this PP code format. The most important is:

- DON'T PUT YOUR OWN NUMERIC LABELS IN UNLESS THEY ARE FOR A SPECIFIC PURPOSE! Use the symbolic labels wherever you can. There are places where this 'rule' cannot be followed (indirect LBLs for example and those connected to hot-keys) and the tool will work with what you have but label re-use is NOT ALLOWED with this tool. However, in most cases, they are just not required anymore -- the tool will select and fill these in for you if and when they are required. You might even see some code compression if you are used to using LBLs willie-nillie.

After a run, intermediate information is available in a file called wp34s_pp.lst in the directory you ran from. This file has the post-processed source that was actually assembled. Use this file if you want to debug your program on a machine or the emulator. It will have fully resolved line numbers, etc. (At the moment it does not retain your original comments. Not crapping please! A 'fix' may be in the works but it is complicated.)

Note that this is currently ONLY available in Perl so if you are using the EXE version of the assembler, you may have to wait a wee bit.

Probably still more bugs in this so let me know. (For a 'simple' little idea for an extension Pauli just tossed out, the code for this feature set is larger than the whole damn original assembler! :-)

We hope you enjoy it!

Source:

LBL'Roc'

CL[alpha]

"WP 34S rocks!"

XEQ Rocks_View

RTN

Rocks_View:: [alpha]VIEW

PSE 08

RTN

Into:

$ wp34s_asm.pl -pp rocks_pp.wp34s -o wp34s-4.dat; cat wp34s_pp.lst

Yields:

// Source file(s): rocks_pp.wp34s, 

// Source File(s): .__0.894647826747136.tmp

// Preprocessor revision: $Rev: $ 

001 /*              */ LBL'Roc'

002 /*              */ CL[alpha]

003 /*              */ [alpha]'WP[space]' // "WP 34S rocks!"

004 /*              */ [alpha]'34S'

005 /*              */ [alpha]'[space]ro'

006 /*              */ [alpha]'cks'

007 /*              */ [alpha] !

008 /*              */ XEQ 99 // XEQ Rocks_View

009 /*              */ RTN

010 /*              */ LBL 99

011 /* Rocks_View:: */ [alpha]VIEW

012 /*              */ PSE 08

013 /*              */ RTN

// %LBLs:

//  Label Step

//  99 => 011

// Total of 1 elements

(...and before you tell me "That's wrong. LBL 99 is actually at step 010!", its 'effective' location is 011 for the purposes of this tool... :-)

[Paul Dale]

Great work!

I never said it would be a simple extension :-)
It is a useful one.

- Pauli

[Neil Hamilton (Ottawa)]

Nah, I was just teasing Pauli!! :-) But is was a strain for my poor brain.

It certainly is a useful concept and I hope someone gives it a good shake. Both the soft labels and JMP instruction should be very attractive to people writing code. Your suggested mods to Franz's code with reminder to "...fix the skips up" after the changes then becomes obsolete! Fantastic -- let the tools do the ugly work while the programmer concentrates on more creative tasks. (My soap box/marketing moment...)

I have checked new versions of both the assembler and PP that fix a few bugs related to regex-active characters within the double quote strings (eg: []^$*()\). You can now even embed a double quote itself within the string (I had thought that one was a permanent goner).

Document is updated to remove the dire warnings in the double quote section. (In retrospect, giving bugs some document space was not such a good idea.)

Now given:

"a= [pi]r[^2]"

"c=2[pi]r"

"s/^(tu)\s*"$/\1\w{3,4}/"

"So, like, she said, "When?""

PP gives you:

001 /*    */ [alpha]'a=[space]' // "a= [pi]r[^2]"

002 /*    */ [alpha]'[pi]r[^2]'

003 /*    */ [alpha]'c=2' // "c=2[pi]r"

004 /*    */ [alpha] [pi]

005 /*    */ [alpha] r

006 /*    */ [alpha]'s/^' // "s/^(tu)\s*"$/\1\w{3,4}/"

007 /*    */ [alpha]'(tu'

008 /*    */ [alpha]')\s'

009 /*    */ [alpha]'*"$'

010 /*    */ [alpha]'/\1'

011 /*    */ [alpha]'\w{'

012 /*    */ [alpha]'3,4'

013 /*    */ [alpha] }

014 /*    */ [alpha] /

015 /*    */ [alpha]'So,' // "So, like, she said, "When?""

016 /*    */ [alpha]'[space]li'

017 /*    */ [alpha]'ke,'

018 /*    */ [alpha]'[space]sh'

019 /*    */ [alpha]'e[space]s'

020 /*    */ [alpha]'aid'

021 /*    */ [alpha]',[space]"'

022 /*    */ [alpha]'Whe'

023 /*    */ [alpha]'n?"'

Before, the tool chain would have done some pretty strange things -- if one or both section didn't lock up!

Cheers...

[fhub]

Hi Neil!

Thanks for your preprocessor - looks indeed to be a very useful tool. :-)

Unfortunately I have again a problem with it: with my TinyPerl it doesn't work - I get the following error message (already when I try to show the helpscreen with -h).

Global symbol "@label" requires explicit package name at (eval 24) line 244.

Global symbol "@label" requires explicit package name at (eval 24) line 254.

Maybe you can have a look at this problem with TinyPerl - but only if it's easy to fix and doesn't make you too much troubles. ;-)

Franz

[Neil Hamilton (Ottawa)]

Quote:

---

Global symbol "@label" requires explicit package name at (eval 24) line 244.

Global symbol "@label" requires explicit package name at (eval 24) line 254.

---

Hi Franz,

This is exactly the same TinyPerl parser bug that showed up in
this thread. The TinyPerl parser is faulty! You already know of my love [not] for TinyPerl.

Why don't you just bite the bullet and get a real Perl environment? Unless you are extraordinarily cramped for disk space, 85MB of space is not really that much in the grand scheme of things.

I will see if I can work around it but it is &^$##$ annoying to have to deal with bad tools when there are perfectly serviceable ones out there. :-<

[fhub]

Quote:

---

I will see if I can work around it but it is &^$##$ annoying to have to deal with bad tools

---

Ok Neil, just ignore my posting - I can live without the preprocessor. ;-)

[Neil Hamilton (Ottawa)]

Quote:

---

Ok Neil, just ignore my posting - I can live without the preprocessor. ;-)

---

Glad to hear it! I am sure that the EXE version will be along soon.

My fear is that it would be the first layer of a very large onion -- this is such a very common syntax in Perl (and a great many other script-type languages as well). Maybe you could ask the people who wrote TinyPerl to fix their tool instead. That would certainly fix the fundamental problem and would be the better long-term solution.

I look forward to hearing back about what they have to say when you make your request for a bug fix! Please post an update to this forum.

Cheers...

[fhub]

Quote:

---

Maybe you could ask the people who wrote TinyPerl to fix their tool instead.

---

Well, if you look at the TinyPerl website you can see that this project's last update was 2003 (and the last posting in the feedback section is from 2005).

So I'm quite sure that nobody is still working on this project.

[Neil Hamilton (Ottawa)]

Quote:

---

I am sure that the EXE version will be along soon.

---

I have the EXE version up in the SVN as well. Just as the initial run of wp34s_asm.exe resulted in a BIG delay while it was dynamically decompressing itself, the combination of wp34s_asm.exe spawning a copy of wp34s_pp.exe will result in a doubly long initial delay!

Fear not, my experience is that they are cached
somewhere on your disk so subsequent runs should be quicker. (As I pointed out in earlier posts, this is a function of the Perl PAR Packer tool that created them. I got it to work and comple and I even reduced its size somewhat but don't know a whole lot more about it besides that.)

I have done some initial testing on one Windows installation so if anyone runs into problems with it, let me know.