several compilers:
- gcc version 4.5.3 (NetBSD nb2 20110806)
- gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
- Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
The warnings were mostly about local variables shadowing others,
unused function parameters, and C++ style comments. Some variables were
indeed used before set.
Note that on Linux, using -std=c99 does stupid things like *remove* the
declaration of strdup() from <string.h>. Therefore I've reluctantly used
-std=gnu99.
They behave observably different from generic string parsing and trying
to account for them generically just gets in the way.
.rept is treated the same as a macro.
this is how it should be according to page 6-42 of the manual.
Kermit does this ugly thing to backpatch some .word value:
435 000070 dial$time 35.
1 000070 modval 35.,dial.time
1 .save
2 000070 .psect modinf
3 000006 . = $$current + dial.time
4 000006 000043 .word 35.
5 000070 .restore
436 000070 wake$string <^E^M>
where the current program section already is modinf. So the .save stores
DOT, it's changed to a lower value (6) to backpatch, and .restore sets DOT
back to 70.
Also, to make Kermit sources work, only increase the local symbol block
counter if there actually was a local symbol used in the block.
This way, conditional inclusions (which include source text only in the
first pass) will have less potential for de-synchronisation between the
passes. After all, if the generated internal local symbol names do
not match, phase errors will result (showing themselves as strange label
redefinition problems).
at least the one of RSX M+ 4.6.
Inconsistent flags given to .PSECT seem to be simply combined, with
nothing special done after pass 1 when re-reading for 2. The situation
at the end of pass 2 wins.
Given the following conditional inclusion, as seen in RSX Kermit-11
sources:
.if ndf, K11INC
.ift
.include /IN:K11MAC.MAC/
.include /IN:K11DEF.MAC/
.endc
macros defined in K11MAC.MAC are unknown when used later on.
The assembler keeps a running count of the line number (stmtno) and
stores it in the macro definition. In the second pass, it tries to avoid
cases of use-before-defined, because it doesn't really forget the
macros.
However, in this case, the second pass has fewer lines, because there
was some conditional inclusion... so when the macro is used in the
second pass, its running line number (including the skipped inclusions)
is lower than the line number where the macro was defined...
The line number check would also interfere when the /PASS:1 and /PASS:2
input file modifiers would be implemented.
It seems to me that in most normal cases, a use-before-defined is
already detected in the first pass, so the check is not really needed.
Therefore I have simply removed it.
