[alpha][space] in WP34S
#1

Marcus has put the text "TVM Slv" at the beginning of my program, but unfortunately this [alpha][space] doesn't really separate both words, it's almost looking like TVMSlv. :-(

But if I look at some error messages (e.g. "Bad mode") this 'space' is ok, it has the full width of a character.

In the opcode table I see [alpha][space] twice, so are there maybe 2 different definitions of the 'space' character (one for normal and one for small text)?

If not then maybe the appearance of this 'space' character could be made a bit wider?

#2

One space is narrow, the other isn't. I've renamed the narrow one which is being picked up by mistake here.

This has nothing to do with the small font which applies to the entire display or not at all.


- Pauli

#3

Ok, then the problem is solved, thanks. :-)

But I'm just curious: for what purpose one would need such a narrow-space when it's almost invisible?

#4

Making the various status indicators on the top line line up correctly. The various indicators don't move around when other indicators are present or not.

- Pauli

#5

Ok, now I got it!

One more question: if I find the same name (token) in the opcode table more often then only once (with 2 different opcodes), is this then a mistake (i.e. should I report it), or is this normal?

#6

It depends on the op-code.

You already know about CLx being there twice.
+/- is the other one that legitimately has two definitions.

There are no other duplicates but if they ever appear, it is likely bad.


- Pauli

#7

Quote:
You already know about CLx being there twice.
+/- is the other one that legitimately has two definitions.

But then I wonder how Neil's assembler can handle these 2 tokens?

A short look at his perl script I don't see anything 'special' for these 2 tokens, so how should the assembler know WHICH opcode it should produce when he finds one of these 2 names in a source file?

Or don't the 2 opcodes (in this case) matter because they have the same code?
#8

Well spotted Franz. This had been discussed previously here.**.

I am a bit with you that I am not exactly sure of the end effect but I suspect that it only has a real difference when editing keyboard entry. Pauli will have to confirm this.

What happens in the assembler is that, when the op-code map is expanded it is placed into 2 hashes. One is keyed on the op-code (hex value) with the payload being the mnemonic (op-code => mnemonic). The other is the opposite: mnemonic => op-code. The first is primarily used by the disassembler, the other by the assembler.

Since I don't over-write any key that previously exists in a hash***, in both cases (CLx and +/-), the duplicate mnemonic in the mnemonic=>op-code table is not recorded -- it is just abandoned. The effect is that when assembling source you will always get the first op-code in the op-code map for these respective mnemonics. This results in a definite loss of information when in source form. (This was also noted in the thread mentioned above.)

So far I don't think it has caused any problems but...

** Note that the date stamps on the thread are often inverted and non-linear. Don't try and follow it linearly from top to bottom.

*** I discovered the duplicates because of the defensive programming habit of always checking a hash table for an existing entry before loading a (key,payload) pair. I think you can still enable the original warning message associated with this by using an undocumented (to the outside world, that is) debug switch on the command line.

#9

Quote:
This had been discussed previously here.**.

Ahhh, I must have overlook this discussion, thanks Neil!

I came across this problem with this [alpha][space] in the TVM program, and as you explained: your assembler just took the first opcode in the table, and exactly this was the 'narrow' space.

Quote:
So far I don't think it has caused any problems but...

Well, the 'space' above was the first then, but I'd say it's indeed a very dangerous situation - as Pauli explained the CLx and +/- go indeed to different code parts, it's just a matter of "which comes first in the opcode table" whether it would work or not.

Not a good solution IMO ...
#10

As I said, there is a loss of precision in source form (predicted and documented)...

The only solution is to add some differentiating information to the two mnemonics. Otherwise I cannot tell them apart.

#11

Quote:
Otherwise I cannot tell them apart.

Yes, I know it's not your fault of course ... ;-)

Now to a completely different question (about your assembler):

While writing my TVM program it happened a few times that I had to insert or delete a line in the source code. Now of course all following line numbers changed, and to get them in order again I've used the following method so far: assemble the source and the disassemble back the *.dat file.

But now in my source I've added several comments in many code lines (after the command with a //), and of course all those comments are gone with my assemble/disassemble method above, so I always had to put these comments in again.

Now my question: is there any (undocumented) trick for your assembler, so that I can use it to ONLY renumber the source lines (without producing any 34s code) and it would keep all comments?

I know I could just write a small program for that purpose myself, but if we already have such a powerful tool like your assembler, I thought that maybe this could be done with your tool, too. ;-)

Edited: 10 Aug 2011, 7:53 a.m.

#12

I am not sure I totally follow. Are you looking for the '-ns' switch to turn step numbers off completely? I think there is a section in the manual about this -- along with the reason for it being there (differencing).

Step numbers are an all or northing deal in the output. They are totally ignored on input.

#13

Quote:
I am not sure I totally follow.

Oh god, that's the problem explaining something in a foreign language! ;-)

No, I meant something else:

I have a program listing (WITH linenumbers) produced by your disassember in *.wp34s format.

E.g. now I add/insert one more command quite at the beginning of the program, so I would have to change all following line numbers manually (I know it's not absolutely necessary because re-assembling this changed file just ignores line-numbers, but it just doesn't look nice).

So all I would want is that the assembler could take this file with the added line and produce a new source(!) file with all line-numbers corrected.

Pauli must have any tools which can do this, because yesterday I posted a few changes to my TVM program, and already a few minutes later these changes were updated in the SVN file and all line-numbers were fixed, too.

But I guess your assembler isn't prepared for this task ...


Edited: 10 Aug 2011, 8:18 a.m.

#14

Quote:
Pauli must have any tools which can do this, because yesterday I posted a few changes to my TVM program, and already a few minutes later these changes were updated in the SVN file and all line-numbers were fixed, too.

I don't have any tools to do this. I used the UNIX command line utility "cat -n" to renumber the relevant sections followed by some clean up editing. It was a manual effort using preexisting tools.


- Pauli

#15

Quote:
I used the UNIX command line utility "cat -n" to renumber ...

Ahh, a happy UNIX user. ;-)

It seems I'll have to look for (or write myself) a Windows counterpart for this "cat" ...

#16

I am not sure I follow yet -- language or no language.

The assembler regenerates the 'step' numbers from scratch unless you ask it not to with the '-ns' switch. (They are really steps, not lines.)

If you are trying to compare 2 files, one with step numbers to one without step numbers or with "different" step numbers, you can use a variety of command line tools to do this. Many O/S's have a command called "cut". You could try this on the files with line numbers and compare the 2 outputs:

$ cut -c 4- your-file-with-step-numbers > your-cleaned-filename

The 4 is appropriate for a file without the "000" type step numbers. If you have "000:" style, use "-c 5-".

If the comment sections get in the way, you will have to scrub those through other means. (This is more difficult with "/* ... */" because you need a state machine -- this is the main reason I personally favour the "//" style comment. They are trivial to deal with.)

$ grep -v "^[ \t]*//" your-file-with-step-numbers | cut -c 4- > your-cleaned-filename

Or, count the lines that need to be removed from the top:

$ tail -40 your-file-with-step-numbers | cut -c 4- > your-cleaned-filename

Where you must replace '-40' with the number of lines counting from the bottom that you are looking to compare.

Repeat this process for both files, if required, and run them through your favorite compare utility.

#17

Quote:
I am not sure I follow yet -- language or no language.

You're right Neil, better let's forget it. ;-)

You're talking about completely different things ...

#18

Quote:
It seems I'll have to look for (or write myself) a Windows counterpart for this "cat" ...

Do yourselve a big favour and get cygwin.

#19

OK, I guess I finally got what you are looking for. Try this. If the line currently doesn't have any step number it will pass straight through. If it does have a step number, it will be regenerated in sequence (lines with no step number will put a hole in your final sequence). Hint, it is keying on the step number being there -- doesn't matter what it is though -- every line could be 000 for all it cares.

We'll call it "renum.pl".

#!/usr/bin/perl -w
my $step = 1;
while(<>) {
chomp; chomp;
if( /^\s*\d{3}(:{0,1}.+)/ ) {
printf "%03d%0s\n", $step++, $1;
} else {
print "$_\n";
}
}

You use it like this:

$ renum.pl < my_disjointed_step_num.wp34s > clean_step_num.wp34s

No doubt it could be written much shorter or in any one of a dozen other languages.

No support offered... :-)

Edit: There was a typo in the formated print line: one too many %0s specifiers. Now fixed. (I guess I have supported it now, haven't I. :-)

Edited: 11 Aug 2011, 5:39 p.m. after one or more responses were posted

#20

Quote:
OK, I guess I finally got what you are looking for. Try this.

WOW, it's working perfectly, many thanks! :-)

If I look at something like "if( /^\s*\d{3}(:{0,1}.+)/ )" I must really say that this Perl is a horrible language - but it seems to be quite powerful OTOH if it needs just so few steps to perform this task.

And IMO these few lines are indeed worth being included in your assembler (maybe with a new option -renum), would be a nice enhancement.

Thanks again,

Franz

#21

I can't follow your discussion. ;-)

The first thing I do with a line numbered source file before I start adding contents to it: Get rid of the nasty numbers. YMMV but my preference is not to have them in the source.

Neil, what if your assembler had a listing option which produced a file with all comments intact and the step numbers added along with the binary output? One such file shall be generated per assembly run. The numbers can help those who prefer to type the stuff in on their calculator instead of loading it.

#22

Quote:
If I look at something like "if( /^\s*\d{3}(:{0,1}.+)/ )" I must really say that this Perl is a horrible language - but it seems to be quite powerful OTOH if it needs just so few steps to perform this task.

While Perl supports this structure, this is standard search terminology available in many languages called regular expressions (often called regex for short).

That particular one is not as ugly as it at first appears:

/  /   -- the evaluation delimiters
^\s* -- zero or more (*) whitespaces (\s)
\d{3} -- exactly three ({3}) numerals (\d)
:{0,1} -- 0 or 1 colons (could also be written :? but I find the more verbose one clearer)
.+ -- 1 or more (+) of any character (.)
( ) -- retain this pattern as a temp variable called $1

Piece of cake!

The rest is Perl and it is a wonderful language for doing this sort of thing. So, respectfully, many many people would take some amount of offense to Perl being called ugly. There are many other languages I would use that term with before I labeled Perl with such a moniker.

And, no, this will not be going in the assembler. You now have the script you need as a separate tool.

The assembler is not a Swiss army knife. It is a screw driver. Occasionally you might want to pry a can open with it, but is not appropriate for carving a roast beef or opening wine bottles.

#23

I don't bother using step numbers either but I don't necessarily get rid of existing ones unless I need to for a secondary purpose (such as diff-ing). The assembler simply ignores them. But if they exist, by garr!, they had better be in the proper 3-digit format with or without a single colon. Otherwise the assembler declares an error and dies. It is very strict on this because it would otherwise be very difficult to parse some of the other operations (single digits, for example).

As far as another output from the assembler, it is possible but I would have to be convinced it had to be within that tool. My preference is for single purpose tools. Maybe we could expand upon the one-off I threw out (above) to do what you want. It works but its error control is nonexistent. If I put the comment FSM into it (about 30 lines of Perl all by itself), it could assign line numbers as required.

Quote:
Neil, what if your assembler had a listing option which produced a file with all comments intact and the step numbers added along with the binary output? One such file shall be generated per assembly run. The numbers can help those who prefer to type the stuff in on their calculator instead of loading it.

I am not sure I get this. If they are typing it in to the calculator, this is implying an assembly-type operation. If that is the case, then the source already exists (possibly pencil-and-paper type). Maybe what you want is just a source formatter that assigns step numbers. If that is the case, stay tuned for the next stage of the assembly project -- that you saw an advanced peek at last week (a symbolic label preprocessor). That tool will essentially do mostly what you want, albeit with scrubbing of comments. But it does assign line numbers. I might be able to figure out how to retain comments within that development. That was not a priority when it was started because it was intended to be an intermediate file format flow-through tool. Let me think on that a bit....

#24

When I started IT, the compiler used to produce a listing of sort as a standard feature. So did any of the assemblers which used to output the source together with the generated op-codes. The op-codes aren't too interesting in this respect but step numbers are.

Pauli brought up the argument of type-in type usage due to lack of the cable. If you are going to type in a complete library, any help in verifying the result is helpful, including step numbers. You can of course use the disassembler but then you lose all the manual formatting (empty lines, indentation) and the comments. A nicely formatted listing is a good documentation, too.



Possibly Related Threads…
Thread Author Replies Views Last Post
  WP-34S: Alpha lock Marcel Samek 15 4,114 07-08-2013, 08:23 AM
Last Post: Reth
  [alpha]SR wp34s Andrew Nikitin 9 2,968 06-17-2013, 11:48 PM
Last Post: Andrew Nikitin
  41-MCODE: Auto XEQ+ALPHA possible? Ángel Martin 5 1,896 05-29-2013, 06:15 AM
Last Post: Ángel Martin
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 1,176 10-04-2012, 04:59 PM
Last Post: Paul Dale
  HP-41C partially repaired, help with "ROM", alpha glitches MattMalone 2 1,181 09-26-2012, 02:26 AM
Last Post: Diego Diaz
  HP50G Max SDcard Storage space?? mr-scorpio 9 2,752 08-22-2012, 09:57 AM
Last Post: Bart (UK)
  OT - Arduino In Space from HP41 Hacker PeterP 3 1,675 06-16-2012, 10:43 PM
Last Post: PeterP
  OT: Space ship Michael Eckstein 18 3,993 04-04-2012, 12:31 PM
Last Post: Michael Eckstein
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 4,970 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 1,447 12-04-2011, 10:49 PM
Last Post: Les Wright

Forum Jump: