need some assistance on assembler LABELS

[vespacla]

Hello everybody,

First of all, I have to tell you that I'm relatively new to assembler.
For my homebrew 6502 project I took "Kowalski"s 6502 assembler and simulator to program the ROM because it looked very simple to use.
I also took some code-parts I found in the internet (e.g. Daryl Rictors PC keyboard connection and others) - and adopted or rewrote to adapt it to my little computer, were necessary. Up to now everything worked fine.

Unfortunately I am now encountering a very strange behaviour dealing with labels. Sometimes it works and assembles, sometimes not.
I have the impression, that it has to do maybe with "how far" the label is. But in my opinion, this shouldn't be. (e.g jsr address - where address can be anywhere in memory)

Or maybe similarities in the name of the labels (like .lp0 .lp1 ??), or my syntax is wrong ?

Maybe it's somehow my fault ... I don't know.

Did someone ever had similar problems with "Kowalskis" 6502.exe ? I'm just completely in the dark !!

Too bad...

I'm willing to upload s.th more concrete, but the code will be a bit longer, because I encountered this only when code gets bigger.


vespacla

[vespacla]

The difference between my file version 3 (_ver3) and version4 (_ver4) is only row 415 and 416. Please have a look at it.

The assembler tells that .printacc is an unknown label name, though it has been used havily before. _ver3 works (using .printacc many times)

I don't understand what I'm doing wrong ...

[Klaus2m5]

Preceeding something with a dot is reserved for directives in this assembler. It is in general never a good idea to start a label with anything other than an alphabetic character (a-z, A-Z) unless the assembler calls for it (for example some assemblers ask for a backslash to preceed local labels).

[BigDumbDinosaur]

The Kowalski simulator's assembler not only recognizes pseudo-ops as dot-something, e.g., .BYTE, it recognizes dot-labels, e.g., .0000010, as local labels whose scope is bounded by the nearest global labels. A simple example will explain this:

Code: Select all

GLOBAL01 <————— a global label

.0000010 <———— a local label <————+
                                  |
         goto .0000010 ———————————+

.0000020 <— another local label <—+
                                  |
         goto .0000020 ———————————+


GLOBAL02 <————— another global label

.0000010 <————————————————————————+
                                  |
         goto .0000010 ———————————+

         if some condition
           goto .0000020       ;won't work, as .0000020 isn't in scope

GLOBAL03 etc.

In reviewing your source code I noted several attempts to reference a local label that was not in scope at the point where the reference was made. For example:

Code: Select all

kbreinit       JSR   KBINIT            ; 
               LDA   puntouno	
               jsr   .printacc 	
KBINPUT        JSR   kbtscrl           ; turn off scroll lock (ready to input)  

In the above code fragment, .printacc would not be in scope, as it is bounded by the labels kbreinit and KBINPUT.

As a fairly general rule, subroutine entry points should be demarcated with global labels. Also, as a matter of style, I use all lower case labels and symbols. Not all assemblers are case-insensitive—the Kowalski assembler is configurable to either recognize or efface case in labels, symbols, mnemonics and pseudo-ops. For consistency, I recommend that you make .opt proc65c02,caseinsensitive the first line in your program. This statement tells the simulator that 65C02 instructions should be supported (but be aware that it is the Rockwell 65C02, not the WDC one, that is supported) and that case-insensitivity is in effect. Case-insensitivity, of course, doesn't apply to quoted strings, such as .BYTE "Text String".

[barrym95838]

BDD,

Your explanation and recommendations make a lot of sense. One puzzle remains: why did two almost identical (but similarly defective) sources receive such different reactions from the assembler? Just dumb luck (no offense intended vesplacla) for version 3???

Mike

[BigDumbDinosaur]

barrym95838 wrote:

Your explanation and recommendations make a lot of sense. One puzzle remains: why did two almost identical (but similarly defective) sources receive such different reactions from the assembler? Just dumb luck (no offense intended vesplacla) for version 3???

Not sure, other than to say that Mike Kowalski probably did some internal tinkering from one revision to the next. The final revision, 1.2.12, is the one I use here.

[BigDumbDinosaur]

barrym95838 wrote:

Your explanation and recommendations make a lot of sense. One puzzle remains: why did two almost identical (but similarly defective) sources receive such different reactions from the assembler? Just dumb luck (no offense intended vesplacla) for version 3???

Not sure, other than to say that Mike Kowalski probably did some internal tinkering from one revision to the next. The final revision, 1.2.12, is the one I use here.

Also, there appears to be some sort of pecking order in the error processing, such that different source files with a common error are treated differently depending on when the code in error is encountered during assembly.

[vespacla]

Thank you very much indeed !

All you guys helped me a lot, and after quickly changing all local labels to global ones, as BDD explained - it worked !! Well, now I can go on with the real task, which is debugging. That's great.

What I am doing is obviously a hobby. It's wonderful to know you in this forum, thank you once again for spending your time on my problem !

[BigDumbDinosaur]

vespacla wrote:

Thank you very much indeed !

All you guys helped me a lot, and after quickly changing all local labels to global ones, as BDD explained - it worked !! Well, now I can go on with the real task, which is debugging. That's great.

What I am doing is obviously a hobby. It's wonderful to know you in this forum, thank you once again for spending your time on my problem !

You're welcome.

Local labels are most useful in subroutines and code blocks. For example, here's some code from a SCSI utilities program I wrote for my POC unit, in which local labels are used:

Code: Select all

;================================================================================
;
;probebus: PROBE SCSI BUS FOR DEVICES
;
probebus shortr
         ldx #0                ;starting SCSI ID
;
.0000010 stx workid            ;current device
         stz devtab,x          ;clear device flag
         cpx hbaid             ;this the HBA?
         beq .0000020          ;yes, mark it present
;
         jsr dotstrdy          ;see if device responds
         ldx workid
         bcc .0000020          ;device present & ready
;
         cmp #ed_check         ;check condition?
         bne .0000040          ;no, device not present
;
.0000020 lda #%10000000
         sta devtab,x          ;mark device present
         cpx hbaid             ;HBA?
         bne .0000030          ;no, actual device
;
         lda #%11111111
         sta devtab,x          ;identify as HBA
         bra .0000040          ;skip ahead
;
.0000030 jsr dostart           ;device start/load...
;
;	————————————————————————————————————————————————————————————
;	DOSTART may return an error but we don't care at this point.
;	————————————————————————————————————————————————————————————
;
         jsr doinqry           ;get device type
         ldx workid            ;current ID
;
.0000040 printchr '.'          ;show some progress
         inx
         cpx #n_scsiid         ;all IDs checked?
         bcc .0000010          ;no, next device
;
         rts
;
;================================================================================
;
;seldev: SELECT DEVICE FOR OPERATION
;
seldev   shortr
         termprn selctdev,0    ;prompt user
;
seldevAA lda #1                ;max input size
         ldx #'0'              ;set input range
         ldy #n_scsiid-1 | m_binasc
         jsr input             ;get device ID
         bcs .0000010          ;aborted
;
         lda strbuf            ;get input
         and #m_ascbin         ;change ID to binary
         sta workid            ;set working ID
         jsr getdtype          ;get device type
         bcs .0000020          ;device not present
;
.0000010 rts                   ;return w/device type         
;
.0000020 termprn devnotpr,0    ;alert user
         sleep 3
         bra seldev            ;try again
;

Use of local labels in this way eliminates the need to have to think up new label names that will never be referenced outside of the subroutine or code block in which they have been defined. Note how I reused the same label names in both subroutines without conflict. This basic technique is used throughout the entire program.

Incidentally, I generally step local labels by 10 so that I can insert new ones if needed without having to rearrange the existing labels.

[GARTHWILSON]

BigDumbDinosaur wrote:

Use of local labels in this way eliminates the need to have to think up new label names that will never be referenced outside of the subroutine or code block in which they have been defined. Note how I reused the same label names in both subroutines without conflict.

The commercial assemblers I've used don't have that capability outside of macros; but to make it simple to think up new label names that won't duplicate ones outside the routine, I use three (or so) letters abbreviating the name of the routine, then put digits after them, like "lmd1", "lmd2", etc.. With structure macros, most local labels are eliminated though. My home-made Forth assembler has a limited number of local labels allowed, and they get re-used.

[teamtempest]

Quote:

I use three (or so) letters abbreviating the name of the routine, then put digits after them, like "lmd1", "lmd2", etc..

I used that same trick with the Merlin assemblers many years ago. It also has the advantage that it's very clear visually which labels mark the start of a routine and which are merely internal to one.

[BigDumbDinosaur]

GARTHWILSON wrote:

The commercial assemblers I've used don't have that capability outside of macros...

It's somewhat surprising that a commercially developed assembler would lack local label capability. The Commodore Dev-Pak 128 assembler supported local labels, and that was a package released in 1986. I remember being enthralled with that feature, as the available assemblers of the time only supported six character label and symbol names. It was a constant challenge to come up with meaningful names and also maintain the basic naming with labels within code blocks.

Dev-Pak recognized a local label as one with a trailing dollar sign in its name, such as L0000010$. The dollar sign didn't count as a character in the name, and Dev-Pak recognized label, symbol and macro names up to 32 characters in length. Most of RAM1 was used to maintain the symbol table and macro dictionary. which meant that the cross-bank kernel subs had to be called to manipulate the table and dictionary. Hence the assembler was rather slow and as the symbol table expanded, the assembler got even slower. However, it was better than nothing.

[GARTHWILSON]

BigDumbDinosaur wrote:

GARTHWILSON wrote:

The commercial assemblers I've used don't have that capability outside of macros...

It's somewhat surprising that a commercially developed assembler would lack local label capability.

In going back to the 2500AD manual, I see the local labels do work the way you're saying. I thought they were local to the particular file, so they could be re-used in another file like if you had INCLude files. I have not used that assembler in about 18 years. Now I use C32.

Quote:

as the available assemblers of the time only supported six character label and symbol names. It was a constant challenge to come up with meaningful names and also maintain the basic naming with labels within code blocks.

I remember it well! I think even Fortran IV run on mainframes was limited to about that many, right? (I had a Fortran IV class in 1982, and I suspect that as usual, the college was behind the times.) When Chuck Moore invented Forth, it was his idea of a language for fourth-generation computers, but I understand he had to run it under a system that only allowed five-character file names, hence "Forth" instead of "Fourth".

[BigDumbDinosaur]

GARTHWILSON wrote:

I remember it well! I think even Fortran IV run on mainframes was limited to about that many, right?

The original FORTRAN was limited to five character identifiers. FORTRAN 66 introduce six character identifiers and Fortran 90 bumped that to 31 characters.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

Dev-Pak recognized a local label as one with a trailing dollar sign in its name, such as L0000010$...Most of RAM1 was used to maintain the symbol table and macro dictionary. which meant that the cross-bank kernel subs had to be called to manipulate the table and dictionary.

Imagine if the C-128 had been 65C816-powered. It could have supported a huge symbol table without a performance penalty.