WP-34S assembler & constants



#2

I am just starting to use the assember and ran across an issue with constants.

I had mistakenly entered a constant on a line as

112

instead of

# 112

I did not get a warning or error and it was only when I was looking at the listing that I realized that that that particular line was silently dropped by the assembler.

I started playing around with the preprocessor and assembler to understand what was going on. I had mistakenly assumed that the preprocessor would take constants and expand them out which it does not do.

However, its current behavior can lead to errors. For example, if you put in the following:

12345
+

You will end up with the following code:

5
+

Has the idea of having the preprocessor expand out constants been previously explored? Would it be difficult? Whether that change is made or not, if a plain multi-digit constant is encountered, the preprocessor/assembler should probably spit out an error.


#3

The assembler can reassemble a listing produced by the disassembler. To make this possible it has been designed to skip any line/step numbers preceding the actual code. A number by itself, at least up to 4 digits, is thus skipped. The 12345 case means that the first four digits are ignored (taken as a line number) and 5 is assembled as a single digit.


#4

Thanks for the explanation. Since it does not seem that the disassembler ever produces a blank line (one with a line number but no code), and it also puts a white space separator between the line number and the code, do you think that there would be any side-effects if I made the following changes to the assembler:

1) If a number that is 4 or less digits is encountered, and there is nothing following it, it is not assumed to a line number, but rather generates an error.

2) If a number that is 5 or more digits is encountered at the beginning of the line (there is no white space separator between the 4th and 5th digits), an error is generated.

That seems as if it would warn someone when a multi-digit constant sneaks in but should not break the disassembler.


#5

Quote:
1) If a number that is 4 or less digits is encountered, and there is nothing following it, it is not assumed to a line number, but rather generates an error.

That won't work, because how would you then enter any number bigger than the #constants (e.g. 550 or 3218) in a program?

For such numbers you have to enter each digit in a separate line, but your suggestion would just remove all those lines (or generate an error)!

Franz

Edited: 27 June 2013, 12:17 p.m.


#6

Right. A Single digit on a line is a valid mnemonic and could be treated as such instead of being processed as a constant.

#7

Is it so hard to put the correct mnemonic ("# ...") in here?

As with many projects, this assembler started out as a very simple and little thing to help out some specific issues I was having with the F/W rapidly and continually changing underneath me. It grew way beyond what I originally envisaged to end up inside the F/W build flow itself. Because of this capability expansion and the many completing requirements (including backward compatibility to older V2 databases), there are many warts and really ugly chucks of code that I would have done very differently had I started with a larger and more complete concept from the beginning.

I am fearful of the law of unintended consequences with this tool set. These changes may well trigger an unintended side effect -- particularly with backward compatibility.

I would prefer that they not be included. Perhaps you can write your own preprocessor that filters your code prior to sending it to this script set. That would avoid disrupting the F/W builds should something go wrong.

Best regards...


#8

You are correct, it is easy to put the "# " in there. This train of though started when I accidentally forgot the "#" and started thinking about whether the assembler could have saved me from that error. I am sure that I am not the first to make that particular error and won't be the last.

I completely understand you concerns about unintended consequences which is why I wanted to bounce it off the group.

Maybe not changing the behavior of the assembler but rather spitting out a warning message when plain multi-digit constants without a "#" are encountered might be a reasonable compromise.

#9

Quote:
Has the idea of having the preprocessor expand out constants been previously explored? Would it be difficult? Whether that change is made or not, if a plain multi-digit constant is encountered, the preprocessor/assembler should probably spit out an error.

The entire suite was designed to be able to have step numbers -- or not -- as the user decided. These step numbers are actually ignored (and probably removed from the line prior to processing -- but I don't recall the exact details). As the documentation states (last paragraph on page 8, last paragraph of Section 4.3 on page 10, last paragraph on page 11, and footnote 15), the step numbers are just plain ignored by the tool.

What happened here was the assembler assumed your constant was a step number and ignored it since it had the format of an optional step number. This left the line as a blank line and the assembler just dropped it completely after that.

I can see that constants were not mentioned very well in the assembler documentation (sorry about that, I'm sure they are in Walter's document) but the doc does tell you how to generate a complete list of legal mnemonics and their associated opcodes (see Section 7.1). So, if your mnemonic isn't in there, it ain't legal (or in this case, it is interpreted as a step number and silently ignored).

I can't see an easy way to both accommodate optional step numbers and have "bare constants".

I hope that helps.

Cheers...


#10

It only seems ambiguous to me if you consider a step number with nothing following it to be legal. Then there is that ambiguity of not being certain whether a single number is a step number with nothing after it, or a constant without a step number.

But, why is a step number with nothing following it considered OK?

If they are really "step numbers", then a step number has to be followed by something else. If its not followed by something else, then the number cannot be a step number because there is no "step". Even if one doesn't allow bare constants, a single digit on a line should generate an error.

Looking at it this way would mean that there is no ambiguity. It would also be compatible with the disassembler because it does not generate empty steps.


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,250 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,829 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  HP Prime Fundamental Constants Timothy Roche 7 3,316 12-04-2013, 04:49 PM
Last Post: Walter B
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,568 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 2,094 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,208 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,718 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,940 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 1,978 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,770 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany

Forum Jump: