WP34S assembler/disassembler in the wild



#17

Thanks to the good graces of the 3 amigos, an assembler/disassembler is now available for alpha testing.

It is written in Perl (5.8+) so that is a minimum requirement, and currently it is only a command line version.

It is available in the ./trunk/tools directory and is called "wp34s_asm.pl". You can get it through the "svn update".

Personally, I envisaged this tool as primarily an archiving and program concatenation tool but you can also write programs on a standard editor using the opcode format described in the output of one one Paul's programs (more on that later when I have had a chance to write documentation.)

It runs in both disassembly and assembly modes. In disassembler mode (triggered by the -dis switch) it writes its output to STDOUT so you will have to redirect the resulting listing to a file if you want to keep it. For example, to see what you had stored in flash-0, use the following:

$ ./trunk/tools/wp34s_asm.pl -dis wp34s-0.dat > myProg.wp34s

In assembly mode, you need to specify the output file because the output is a binary image (-o switch and *no* -dis switch):

$ ./trunk/tools/wp34s_asm.pl myProg.wp34s -o wp34s-0a.dat

These complimentary commands "should" result in the recreated flash image (wp34s-0a.dat) being identical to the original (wp34s-0.dat):

$ diff wp34s-0a.dat wp34s-0.dat

[Note that a few things could go "wrong" resulting in files that don't match but are otherwise functionally identical. More in the TBD documentation.]

I have tested it with the very small suite of WP34S programs I have at my disposal but it could really use some extra eyes and more sophisticated WP34S programs than my simple coding attempts.

There is a reasonable help screen that you can get by using the '-h' switch:

$ wp34s_asm.pl -h

As I said, it is very early in its development so it will undoubtedly have issues. Hopefully I'll find them before you do. :-) It will not currently eat the output from Paul's disassembler but that should be trivial to include in a day or two.

One really nice feature is that, once you have the programs in source form (what I am calling "*.wp34s"), the assembler can concatenate more than one program into a single flash image -- limited by the 506 word flash size limit. These source files may or may not have line numbers but they are ignored by the assembler in any case. For example:

$ wp34s_asm.pl gc.wp34s fp.wp34s moonlander.wp34s -o wp34s-3.dat

It was written to be platform independent but I have not been able to test it on an Apple yet.

I hope you find it useful! Let me know what dumb errors I have made (but be gentle!).

Best regards...


#18

Quote:
It was written to be platform independent but I have not been able to test it on an Apple yet.

Is there no compiler in PERL so that you could make a Win32 executable for us?

#19

Perl is an interpreted scripting language and thus has no compiler itself (that I am aware of). Someone else may know more about a Perl compiler than I.

There are many good Perl packages available to choose from. On Windows I tend to use cygwin but the equally free Active State package has very good reviews and is available on most platforms that would matter to this community. Strawberry Perl is another one that is widely used with very good reviews -- and available as a Portable installation (ie: on a USB drive).

While cygwin is very attractive package for Windows people wishing to run Unix-like commands, it can be a challenge to install for novices. Not so with Active State or Strawberry (to the best of my recollection).

I have yet to see a Linux distribution without a Perl package as part of the installation.

I hope that helps.


#20

Quote:
I have yet to see a Linux distribution without a Perl package as part of the installation.

MacOS doesn't seem to be a problem either but I haven't started your software on it yet.

#21

Quote:
There are many good Perl packages available to choose from.

Well, I've had a look at these programs but I really don't want to install a 200MB Perl package just for running one single script.

So I continued my search and in fact found a very small (minimal) Perl system (TinyPerl, only 600kB) here:

http://tinyperl.sourceforge.net/

Unfortunately when I try to run your script with "tinyperl wp34s_asm.pl" I always get the following error message:

"Global symbol "@base_mnemonic" requires explicit package name at (eval 24) line 781."

Any idea what might cause this error and how to solve this problem?

(I have not clue at all about Perl ...)

Franz


#22

Hi Franz,

I suspect that it is a "tinyperl" bug and its parser is likely mistakenly interpreting "${base_mnemonic}[->]" as "${base_mnemonic[->]}". The first means "access the scalar value called $base_mnemonic and append the string '[->]'" (the intended action) while the second means "access the '->'-th element of the @base_mnemonic array" (a wee bit of nonsense since '->' does not resolve into anything meaningful in this case). There is no array called @base_mnemonic so their interpreter pukes telling you that the global array doesn't exist.

None the less, I can probably work around their issue with a small patch. Stay tuned!

(I suspect that you are looking at revision 1183 of the wp34s_asm.pl script. In future, can you do an "svn log wp34s_asm.pl" and mention the revision number you are looking at when you report an issue? Thanks...)

BTW: I have tried to find a Perl compiler as per your previous comment. Active Perl has such a compiler but you need a paid-up license to use it (there are many good, free Perl interpreters so I have no intension of paying for it!). I have successfully generated a portable Windows executable using an evaluation license of the Active Perl PDK and it works fine. Unfortunately, the terms of the eval license mean that I am prohibited from uploading the executable and it ceases to function after 21 days. However, I am still (semi-actively) looking for a solution for you.

That being said, with the size of disks these days, 200MB is a "fart in a hurricane". If you are really concerned about space, you might be able to install a much smaller subset of the Perl libraries -- though I have never tried. Someone else might know better than I.

Incidentally, I spent a day testing the script against various downloads of Perl on a "clean" Windows box. Strawberry Perl has a "portable" version that can work directly from a USB stick and it works just fine.


#23

Hi Neil,

thanks for your answer and that you'll try to solve this problem! :-)

And yes, it was the latest SVN 1183, I'll report the number whenever I post any issue again.

As for the compiler: well, such a trial-limit won't be a big problem for me, I'm quite experienced in 'prolonging' such restrictions. ;-)

But even this TinyPerl is able to produce an executable from the Perl script (with the option -bin), so maybe I could do it this way when the script works again in TinyPerl.

Unfortunately I've read (and also confirmed already) that these TinyPerl executables can't handle any additional commandline options of the script, because TinyPerl itself uses these options itself. So I guess a batchfile will rather be my solution.

A "fart in a hurricane"? LOL, I've never seen this expression before, but I can imagine what you mean.

Well, since we have no hurricane(s) here, even a "fart" alone isn't really a nice thing, is it? ;-)

Franz

Edited: 30 June 2011, 10:57 a.m.


#24

Hi Franz,

I have put in a workaround to get past the faulty parser in tinyperl but you will have to do a few other things as well to get it working with the assembler/disassembler script.

Background: Perl has the ability to have a __DATA__ segment attached (usually?) at the bottom of a script. This can be read just like any normally opened file using the file handle "DATA". This is standard Perl! However, tinyperl does not seem to recognize the __DATA__ segment. Therefore, you are going to have to manually copy from lines 1197 to the end (ie: the compressed opcode table) to a separate file which you can ask my script to read in using a pre-existing facility (the '-op' switch). This pre-existing facility was planned to be used to update or "down-date" :-) to newer or older SVN opcode maps but it can also be used for this workaround as well.

So here is what you need to do in detail:

1) Search for the text "__DATA__" in the wp34s_asm.pl script (currently line 1196) and copy all the lines *below* that to a file we will call "svn_1186.op".

2) To assemble a source file, use the following (I am assuming you are in the library directory for now):

$ c:\tinyperl\tinyperl.exe ..\trunk\tools\wp34s_asm.pl -op svn_1186.op 8queens.wp34s -o wp34s-0.dat

This will assemble the 8-Queens program into a flash image for slot 0. By using the '-op' switch, the assembler will use the explicitly referenced opcode map (svn_1186.op) instead of the internal one located after __DATA__. After the assembley has completed, make sure that the CRC16 matches the one I have put in the listing (shown below)! [I *really* don't trust tinyperl!!]

// CRC16: 520A
// Total words: 32
// Total steps: 31

3) To disassemble a flash image, use the following:

$ c:\tinyperl\tinyperl.exe ..\trunk\tools\wp34s_asm.pl -op svn_1186.op -dis wp34s-0.dat > mysrc.wp34s

This will disassemble the flash image (wp34s-0.dat) into a source file called "mysrc.wp34s".

I must warn you that, based on what I have seen, I have little faith in this tinyperl interpreter. The above workarounds are solely because tinyperl itself has bugs. I will reiterate that these are *not* faults in the original script! If I were you I would stick with the mainstream Perl bundles like Active State Perl -- which is 85MB not 200! The mainstream downloads work as expected!

Best of luck!


#25

Hi Neil!

WOW, that was indeed a more than detailled description, many thanks! :-)

(sorry that you had so much troubles just because of me ...)

But now everything is working fine, I've made 2 batchfiles (asm.bat, conv.bat) for your 2 Perl scripts, so that I don't have to type so much. And besides these problems with your previous script TinyPerl seems to work correctly now.

I don't remember which of the 2 Perl distributions (which you've recommended last time) I have downloaded, but when I wanted to install it I just saw "Disk space used: 200 MB", and so I immediately cancelled the installation.

Even if it's in fact only 85 MB this would definitely be too much for me, because your script is the only Perl program that I have (and probably the only one I'll ever need).

Before installing 85 MB for that one single script I would rather write such a (Dis)Assembler myself in any other programming language that I know (probably in Delphi). ;-)

But I think this will not be necessary because now your scripts are working fine with TinyPerl, and I hope this will stay so for future versions, too.

Thanks again for your 'extra' work, :-)

Franz


Edited: 1 July 2011, 8:52 a.m.


#26

Hi Franz,

I have just done a little more work with TinyPerl (you can see I am now even capitalizing it correctly!) and I may have been a little harsh on my first impression. Once you work around its eccentricities, it seems to be OK. There have certainly quite a few complimentary statements made online about it (mostly "Perl on a floppy" type thing...). But it could use some work...

I have come up with a workaround for its broken __DATA__ segment -- it is a bit ugly but it is functional. So I have a version that does not require you to extract the compressed opcode table to a separate file.

I have also worked around the compiled version not having access to command line parameters (by injecting the command line via an environment variable).

I am not really keen to let this one loose into the general public because it is a hack to fit a broken tool, but I would be willing to let you have it if you wish. You can compile it down to an executable using the TinyPerl compiler.

Let me know if you want these mods and let me know how I can send them to you.

All I ask is that you try out the tool and report back to the site how you get on. Comments and suggestions are (usually) welcome! :-)

Best regards...


#27

Quote:
I have also worked around the compiled version not having access to command line parameters (by injecting the command line via an environment variable).

Hey, that would even be my main wish - such a single EXE is definitely the most comfortable method!

You can send me your files to my email-address:

fhub@gmx.at

Of course I'll immediately test it and report back if it works! :-)

Franz


#28

Ok Neil,
I've now received your file and tested it, but my first impression is not very good!

First I found that this compiled EXE still needs the 2 files perl58.dll and lib.zip for running (I thought those would be 'included' in the EXE when compiling the script!), they must be in the current folder and so this is no advantage at all.

And also with this enviroment variable I would have expected an other behaviour: I thought that the EXE would get its commandline parameters _automatically_ via the environment variable (there's a variable CMDLINE in Windows for this purpose), but as you wrote one has to set all wanted parameters _manually_ via "set WP34S_CMD=..." and then run the EXE.

Well, I would say that's even more complicated than running the EXE via a batchfile where I can enter all parameters directly.

The only advantage I see so far is that this external opcode-file (and the -op parameter) isn't necessary anymore. But I think this won't justify all those modifications (and extra troubles with future updates), because using my current method with a batchfile (which already includes this "-op opcode.lst") is neither more nor less 'work' than this compiled EXE - it's rather the opposite, because with this batchfile I don't need to set this environment variable separately.

So my conclusion is: let's forget this compiled script. ;-)

Whether you prefer to use your new 'TinyPerl method' for the opcode table or stay with your last method of the official version that's your decision - for me it's absolutely no problem to create a new external opcode file whenever your script changes in the future.

The most important thing for me was that your Perl script is working at all with this TinyPerl, and this has already been achieved with your last changes in todays SVN release.

Thanks again for all your efforts, :-)

Franz

Edited: 1 July 2011, 2:24 p.m.


#29

Ok, Franz. Sounds good. You have basically identified the limitations of TinyPerl and my suspicion about the paths that I alluded to in my email.

The environment variable technique was an UGLY workaround at best -- I understand this and I too think it is an awful solution. However, I suspect that if you wanted to, you could construct a batch file that decomposes a Windows 'cmd' command line, sets the the environment variable to the batch command line and launches the EXE from a suitable directory.

Personally, I am still *not* in love with TP and will stick with a pure Perl script until I find a good compiler solution.

However, I think you'll agree that it was worth the shot to see what would happen. :-)

Best regards...


#30

Quote:
However, I suspect that if you wanted to, you could construct a batch file that decomposes a Windows 'cmd' command line, sets the the environment variable to the batch command line and launches the EXE from a suitable directory.

Well, the Windows batch file 'features' are so limited that I won't know how to do this (i.e. split an enviroment variable into its parts).
Quote:
Personally, I am still *not* in love with TP and will stick with a pure Perl script until I find a good compiler solution.

Yes, I agree that this will be the best solution - as long as you still keep those changes in the current SVN version, i.e. as long at your script runs at all in TinyPerl! ;-)

BTW, what about this: couldn't you combine your 2 scripts to one, so that your wp34s_conv can be simple be used from your wp34s_asm script e.g. via the option "-conv"? Not important, just an idea ...

Franz


Edited: 1 July 2011, 3:24 p.m.


#31

Quote:
BTW, what about this: couldn't you combine your 2 scripts to one, so that your wp34s_conv can be simple be used from your wp34s_asm script e.g. via the option "-conv"? Not important, just an idea ...

Yes. The convert script was written for the sole reason that I needed "live" test code for the main script. I did not have enough real source of my own to use as test data so I converted the XROM programs. I had not really intended to release that script into the open since it would be so little use for most people. At some point, I do intend to fold its functionality (and more) into the main script but it is not a priority just yet. Since the convert script works just fine as it is at the moment, I am in no great rush. I have a few other things closer to the radar. :-)

BTW: What are you using the convert script for? Are you "harvesting" XROM programs for other uses?

Cheers...


#32

Quote:
BTW: What are you using the convert script for? Are you "harvesting" XROM programs for other uses?

Oh no, I was just curious to see what it is good for. ;-)

So far I've not written any program for the WP34s, because there are so many limitations of this calc (compared to my HP-48GX or TI-92Plus), so that I don't really know WHAT programs I should write ...

Regards,
Franz


Possibly Related Threads...
Thread Author Replies Views Last Post
  WP-34S assembler & constants Marcel Samek 8 477 06-27-2013, 12:27 PM
Last Post: Marcel Samek
  Patch for wp34s assembler Marcel Samek 0 163 06-26-2013, 05:35 PM
Last Post: Marcel Samek
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 277 10-04-2012, 04:59 PM
Last Post: Paul Dale
  HP 71b Assembler Michael Fehlhammer 2 253 09-06-2012, 08:20 AM
Last Post: Michael Fehlhammer
  [WP34s] Assembler question fhub 6 386 05-14-2012, 03:08 PM
Last Post: Marcus von Cube, Germany
  WP 34S: Simplification to the Assembler Marcus von Cube, Germany 2 245 05-06-2012, 02:41 AM
Last Post: Marcus von Cube, Germany
  HP-41 NUT Assembler question MichaelG 6 416 02-14-2012, 03:35 AM
Last Post: MichaelG
  HP-41 MCode Assembler/Linker 32-bit version MichaelG 19 996 01-22-2012, 12:44 PM
Last Post: MichaelG
  [WP34s] Assembler problem fhub 2 250 01-19-2012, 07:32 PM
Last Post: Neil Hamilton (Ottawa)
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,071 12-06-2011, 11:07 AM
Last Post: Namir

Forum Jump: