Spaced out register names in Motorola User Group code triggers "undefined label" error

[ExileInParadise]

While experimenting with some historical source from the Motorola User Group code from their old BBS, I found many contributed 6800 programs have code where there is a space between part of an operation and single register and then the operand.

A09 sees this as an attempt to use an undefined label instead of a register specifier.

Example Run:

 ./a09 -M09 -L RANDOM.asm
A09 Assembler V1.50
RANDOM.asm(58) : error 3: Undefined label in "       ASL A"
RANDOM.asm(60) : error 3: Undefined label in "       LDA B 1,X "
RANDOM.asm(61) : error 3: Undefined label in "       ASL B MULTIPLY BY 2**2"
RANDOM.asm(62) : error 3: Undefined label in "       ROL A"
RANDOM.asm(63) : error 3: Undefined label in "       ASL B"
RANDOM.asm(64) : error 3: Undefined label in "       ROL A"
6 error(s) in pass 2

The example user group code that triggers this:

       NAM RANDOM
*
*      REV. 1.0
*
*GENERATESA (PSUEDO)RANDOM SEQUENCE OF 16 BIT
*BINARYNUMBERS R(N) USING A LINEAR CONGRUENTIAL
*SEQUENCEOF THE FORM: R(N+1) = (R(N)*A+C)MOD 2**16
*WHERE A = 2**11+2**2+1  AND  C = $3619.
*
*CAUTION: IF A K-BIT RANDOM NUMBER IS NEEDED AS
*OPPOSEDTO A 16 BIT RANDOM NUMBER, USE THE  MOST
*SIGNIFICANTK BITS (THE LEAST SIGNIFICANT K BITS
*ARE   NOT AS RANDOM ).
*
*REFERENCE: DONALD E KNUTH, "THE ART OF COMPUTER
*PROGRAMMING"VOLUME II , ADDISON WESLEY PUBLISHING
*COMPANY,1969.
*
*THE   RANDOM NUMBER GENERATOR IS WRITTEN AS A SUB-
*ROUTINECALLED "RNDGEN WHICH IS REENTRANT AND MAY
*BE    STORED IN RAM OR ROM.  TWO BYTES OF RAM ARE
*REQUIREDTO STORE THE CURRENT 16 BIT RANDOM VALUE.
*
*REGISTERSUSED: A,B,C,X
*
*INPUT: THE CURRENT 16 BIT RANDOM NUMBER WHICH IS
*STOREDAS TWO BYTES AT RAM ADDRESSES Z (MOST
*SIGNIFICANTBYTE) AND Z+1 (LEAST SIGNIFICANT BYTE).
*THE   INDEX REGISTER X MUST CONTAIN THE ADDRESS Z.
*
*OUTPUT:A NEW 16 BIT RANDOM  NUMBER WITH THE MOST
*SIGNIFICANTBYTE STORED IN RAM LOCATION X AND
*ACCUMULATORA AND THE LEAST SIGNIFICANT BYTE STORED
*IN    RAM LOCATION Z+1 AND ACCUMULATOR B.  THE INDEX
*REGISTERX WILL STILL CONTAIN THE ADDRESS Z.
*
*CALLINGSEQUENCE+
*                        LDX  #RNDADD   RANDOM # STORE
*                        JSR  RNDGEN
*
*PROGRAMSTORAGE:  24 BYTES
*
*      EXECUTION TIME(1MHZ MPU CLK):  56 MICROSECONDS
*
*
*      
       ORG $0000
RNDADD RMB 2 RANDOM NUMBER STORAGE
*
*      
       ORG $0400
RNDGEN LDAA 1,X COMPUTE (R(N)*2**9)MOD 2**16
       ASL A
       ADD A 0,X ADD R(N) TO RESULT
       LDA B 1,X 
       ASL B MULTIPLY BY 2**2
       ROL A
       ASL B
       ROL A
       ADDB 1,X ADD R(N) TO RESULT
       ADCA 0,X
       ADDB #$19 ADD OFFSET C=$3619
       ADCA #$36 
       STAA 0,X STORE NEW RANDOM NUMBER
       STAB 1,X IN LOCATION RNDADD.
       RTS RETURN TO MAIN
       END

If I manually remove the space from ASL A to form ASLA, ADD A to ADDA, and so on, then A09 assembles as you would expect.

A09 is doing the right thing but it does highlight a historical oddity in coding style I thought you might be interested in.

[Arakula]

I am ... especially since this should be handled (see void oneaddr(int co), approx. line 5390). I'll look into it.

[Arakula]

Hmmm. OK ... actually, if you add -oTSC to the command line, A09 tolerates most of the 6800 relics. But not all; LDA B 1,X, for example, doesn't work at the moment. Guess I'll have to do something ...

[Arakula]

OK, I uploaded a new version that can handle your file. It gets a bit miffed (i.e., it spits out a lot of ambiguity warnings), but that's intentional.