|
Post by elmer on Dec 2, 2021 23:08:24 GMT
Here is what the ASM6 (which is exclusively using +/- for nameless labels) readme has to say about labels: ... I think they are nice and use them sometimes in smaller code snippets. ASM6 doesn't allow you to mix local and nameless labels though which is kind of annoying and makes them much less useful. 64TASS supports both the +/- style of nameless labels and the truly nameless (just a colon) labels and can mix properly with local labels which is one of many reasons I like it. It uses underscore for local labels though, kind of weird but easy to type. Thanks for the explanation and the text from the manual. Hahaha ... there are so many different syntax variations in so many different assemblers! Well, the syntax that turboxray put in a decade ago didn't really match way that ASM6 seems to work ... and it is gone now. I have implemented the Kick Assembler "multi-label" syntax, and it wasn't too horrible to do, but they're implemented as global labels, so you can't really mix them with local labels ... although I'm not sure why you'd want to, since IMHO the two methods are basically designed to solve the same problem.
|
|
|
Post by elmer on Dec 2, 2021 23:20:10 GMT
Ok, I understand the intent better now. (But I don’t like it) Seems pretty fringe-ish… Yep, I have to agree. I can't understand why you'd want to use those "nameless" variables if you already have the ability to use local variables, it just makes your code harder to read and more prone to errors when you move things around. In this case I just want us PCE folk to have access to a particular assembly-language code resource that uses the Kick Assembler style of "multi-labels", and so I'm willing to do the work of adding them to PCEAS.
|
|
|
Post by turboxray on Dec 3, 2021 0:10:53 GMT
Yeah, I'm in the camp that if you have a point that you need to jump to, then take the time to make a name/label for it. There's functionality associated with it - give it a description via a proper label.. or something close to it. Or maybe I'm just used to PRs being brutal callouts culture where you better have a really good explanation for doing something else you get torn apart in the review haha.
|
|
|
Post by turboxray on Dec 3, 2021 0:17:10 GMT
.. Kick Assembler style of "multi-labels" Those are just as bad!
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Dec 3, 2021 22:49:46 GMT
I can't understand why you'd want to use those "nameless" variables if you already have the ability to use local variables, it just makes your code harder to read and more prone to errors when you move things around. For example you may have a pretty large routine with many smaller loops, the loops in this case doesn't really need super descriptive labels so you give them simple local label names like ".loop1", ".loop2", ".loop3" etc. In such cases using nameless labels instead of local labels makes a lot of sense. If you realize that you put them in the wrong order or need to insert a new loop between two others you would have to renumber all the local labels again. Nameless labels on the other hand are very easy to copy-paste around and are always conflict-free and self-contained no matter where they are put.
Since ASM6 doesn't allow nameless labels mixed with local labels they are not fully conflict-free and self-contained though. You are basically forced to start a new scope (which in ASM6 can only done with a new global label) before you can use them, something that could be inconvenient in the example case. You could get around it if you only use nameless labels and no local ones in a routine, but as local labels are more useful in most other cases when a descriptive name is needed to make the code readable, this is not a very good workaround except for very small routines with only a loop or two (and in such routines local labels tends to do the same job fine as you said).
Edit: It seems I was wrong about 64TASS supporting truly nameless labels with just a colon. 64TASS anonymous symbols are always + or - and only references to them seems to use ++, -- etc unlike ASM6.
|
|
|
Post by elmer on Dec 6, 2021 1:20:14 GMT
Edit: It seems I was wrong about 64TASS supporting truly nameless labels with just a colon. 64TASS anonymous symbols are always + or - and only references to them seems to use ++, -- etc unlike ASM6. I think that we're definitely in the realm of personal-preferences here, and I understand what you're saying about the "nameless" variables, but I just don't agree ... which is absolutely no reason for me to remove existing functionality. But, because the implementation in PCEAS (using local variables) didn't match ASM6, and it wasn't really a good replacement, I don't feel bad in nuking it. The new KickAssembler "multi-label" syntax seems to be pretty close to the 64TASS version of "nameless" variables, especially now that I've fixed my error and made sure that the "multi-labels" do not affect the current scope of local-labels. Hopefully you'll either find it useful, or find that the capabilities that we get by implementing it are worth the cost of changing the old behavior.
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Dec 6, 2021 20:12:07 GMT
Although I find nameless labels useful at times I agree with you that the half-working implementation in PCEAS should be nuked. The point with nameless labels is that they don't have unique names and can be copied many times over since they are referenced relatively by position rather than absolutely by a unique (within scope) identifier like global and local labels are. It sounds like the PCEAS implementation was really just local labels with + and - as allowed characters in the label name, and in that case pretty pointless.
Nameless labels works exactly the same in ASM6, 64TASS and CA65, only the syntax is different. I just checked multi-labels and if I understand it correctly multi-labels are exactly the same thing as nameless labels.
|
|
|
Post by elmer on Dec 7, 2021 0:42:48 GMT
I've been making a few additions to PCEAS, but haven't been checking them into github so that I don't break the repository, just in case I screwed things up! I think that I'm finished now, and everything that worked before still seems to be working, i.e. I can still build all of the HuC example code and Catastrophy. Before I check everything in ... can folks check out this documentation of the changes, and let me know if anything sounds crazy! As you read the document, I think that it'll become pretty obvious why I've been adding stuff, and what my eventual goal is. ; **************************************************************************** ; **************************************************************************** ; ; SUMMARY OF LATEST CHANGES TO PCEAS ; ; **************************************************************************** ; ****************************************************************************
; **************************************************************************** ; ; Defining data (traditional PCEAS pseudo-ops) ... ;
01:6000 01 02 03 04 db 1,2,3,4,"hello",0 01:6004 68 65 6C 6C 01:6008 6F 00 01:600A 01 02 03 04 .db 1,2,3,4,"hello",0 01:600E 68 65 6C 6C 01:6012 6F 00
01:6014 34 12 dw $1234,$5678 01:6016 78 56 01:6018 34 12 .dw $1234,$5678 01:601A 78 56
01:601C 34 dwl $1234,$5678 01:601D 78 01:601E 34 .dwl $1234,$5678 01:601F 78
01:6020 12 dwh $1234,$5678 01:6021 56 01:6022 12 .dwh $1234,$5678 01:6023 56
01:6024 78 56 34 12 dd $12345678,$8765 ; <-- new! 01:6028 65 87 00 00 01:602C 78 56 34 12 .dd $12345678,$8765 ; <-- added in 2020 01:6030 65 87 00 00
01:6034 00 00 00 00 ds 8 01:6038 00 00 00 00 01:603C 00 00 00 00 .ds 8 01:6040 00 00 00 00
01:6044 FF FF FF FF ds 8,255 ; <-- new syntax! 01:6048 FF FF FF FF 01:604C FF FF FF FF .ds 8,255 ; <-- new syntax! 01:6050 FF FF FF FF
; **************************************************************************** ; ; Defining data (for compatibility with other assemblers) ... ;
01:6054 68 65 6C 6C text "hello" ; <-- new! 01:6058 6F 01:6059 68 65 6C 6C .text "hello" ; <-- new! 01:605D 6F
01:605E 01 02 03 04 byte 1,2,3,4,"hello",0 01:6062 68 65 6C 6C 01:6066 6F 00 01:6068 01 02 03 04 .byte 1,2,3,4,"hello",0 01:606C 68 65 6C 6C 01:6070 6F 00
01:6072 34 12 word $1234,$5678 01:6074 78 56 01:6076 34 12 .word $1234,$5678 01:6078 78 56
01:607A 78 56 34 12 dword $12345678,$8765 ; <-- new! 01:607E 65 87 00 00 01:6082 78 56 34 12 .dword $12345678,$8765 ; <-- new! 01:6086 65 87 00 00
01:608A 00 00 00 00 fill 8 ; <-- new! 01:608E 00 00 00 00 01:6092 00 00 00 00 .fill 8 ; <-- new! 01:6096 00 00 00 00
01:609A FF FF FF FF fill 8,255 ; <-- new! 01:609E FF FF FF FF 01:60A2 FF FF FF FF .fill 8,255 ; <-- new! 01:60A6 FF FF FF FF
; **************************************************************************** ; ; New pseudo instructions (that currently do nothing) ... ;
.cpu _65c02
.encoding "ascii" ; For data in ".text"
; **************************************************************************** ; ; New pseudo instructions (that actually do something) ... ;
60AC align 4 ; Like a ".org" 60B0 .align 16
60B0 align 4 60B0 .align 16
0008 .const myconst = 8 ; Same as a ".equ" 0020 .label mylabel = 32 ; Same as a ".equ"
2004 .segment zp ; Same as a ".zp" 2309 .segment Bss ; Same as a ".bss" 6000 .segment Data ; Same as a ".data" 60B0 .segment Code ; Same as a ".code"
6000 * = $6000 ; Same as a ".org" 6003 * = * + 3 ; Same as a ".org"
.kickc ; Switch to KickC mode .pceas ; Switch to PCEAS mode
; **************************************************************************** ; ; New support for KickAssembler's style of "multi-labels" ... ; ; A "multi-label" is a location label that can be declared more than once. ; ; These are useful to prevent name conflicts between labels. A multi-label ; starts with a ‘!’ and when you reference it you have to end with a '+' to ; refer to the next multi-label or '-' to refer to the previous one. ; ; Applying more than one '+' or '-' will skip labels, so '+++' will jump to ; the third label. ; ; Multi-labels are global labels, and so references can be made to them from ; outside the current local label scope, which they do not affect. ;
01:6003 4C 1C 60 jmp !+ ; Multi-labels are global.
01:6006 EA new_locals: nop ; New scope for local labels.
01:6007 AD 1C 60 .label1: lda !+ +0 ; You can do math on them.
01:600A BD 1E 60 !skip: lda !+++,x 01:600D 4C 0D 60 !skip: jmp !skip- 01:6010 4C 1E 60 !skip: jmp !+++ 01:6013 4C 1D 60 jmp !++ 01:6016 4C 1C 60 jmp !+
01:6019 4C 28 60 jmp .label2 ; Still available!
01:601C EA !: nop 01:601D EA !: nop 01:601E EA !: nop
01:601F 80 FD bra !- 01:6021 80 FA bra !-- 01:6023 80 F7 bra !---
01:6025 4C 07 60 jmp .label1 ; Still available!
01:6028 4C 0A 60 .label2: jmp !skip---
01:602B EA more_locals: nop ; New scope for local labels.
; jmp .label2 ; Error, not defined in new scope. 01:602C 4C 13 60 jmp !skip- +3 ; Still works!
; **************************************************************************** ; ; New support for KickAssembler's style of "label scopes" ... ; ; If you declare a scope, by using '{' and '}' after a label, then you can ; access the labels inside the scope as fields on the declared label. ; ; This is a way to make the labels in your functions seem to be local, but ; still have them accessible in global scope. ; ; Note: From a practical standpoint, this is quite a good match for the way ; that the C language accesses variables and labels that are defined within ; a function. ;
0004 stringLen = 4 ; Define the length of a string 01:602F 00 00 00 00 string: .ds stringLen ; Global variable.
01:6033 A9 20 lda #' ' 01:6035 8D 3D 60 sta clearString1.fillbyte + 1 01:6038 20 3C 60 jsr clearString1 01:603B 60 rts
clearString1: { ; Open scope on "clearString1"
01:603C A9 00 fillbyte: lda #0 ; Defined as "clearString1.fillbyte" 01:603E A2 03 ldx #stringLen - 1 ; Access the global label 01:6040 9D 47 60 !loop: sta string, x ; Access the version in this scope 01:6043 CA dex 01:6044 10 FA bpl !loop- 01:6046 60 rts
01:6047 00 00 00 00 string: .ds stringLen ; Defined as "clearString1.string"
} ; Close scope of "clearString1"
; The above code fills the string with spaces. The code that ; calls the clearString1 subroutine use clearString1.fillbyte ; to access the fillbyte label. ; ; If you use the label directive to define the fillbyte label, ; the code can be a cleaner ...
01:604B A9 61 lda #'a' 01:604D 8D 55 60 sta clearString2.fillbyte 01:6050 20 54 60 jsr clearString2 01:6053 60 rts
clearString2: { ; Open scope on "clearString2"
6055 .label fillbyte = *+1 ; Defined as "clearString2.fillbyte" 01:6054 A9 00 lda #0 01:6056 A2 03 ldx #stringLen - 1 01:6058 9D 2F 60 !loop: sta string, x ; Either the global variable 01:605B 9D 47 60 sta clearString1.string, x ; Or the one in clearString1 01:605E CA dex 01:605F 10 F7 bpl !loop- 01:6061 60 rts 01:6062 55 60 .dw fillbyte ; To show that it's the local one.
} ; Close scope of "clearString2"
; **************************************************************************** ; ; The 'A'-for-accumulator in ASL/DEC/INC/LSR/ROL/ROR is now optional ... ;
01:6064 1A inc a 01:6065 1A inc 01:6066 2A rol a 01:6067 2A rol
; **************************************************************************** ; ; New ".z" and ".a" instruction suffixes for addressing modes, to add to ; the existing, but undocumented, ".l" and ".h" suffixes from v3.21 ... ;
; lda #__ax ; Error, because __ax > $FF. 01:6068 A9 F8 lda #<__ax ; One method to get lo-byte. 01:606A A9 20 lda #>__ax ; One method to get hi-byte. 01:606C A9 F8 lda.l #__ax ; Or ... lo-byte of a word. 01:606E A9 20 lda.h #__ax ; Or ... hi-byte of a word.
01:6070 B9 F8 20 lda __ax, y ; Default is absolute mode. 01:6073 B9 F8 20 lda.l __ax, y ; Addr+0 for lo-byte of a word. 01:6076 B9 F9 20 lda.h __ax, y ; Addr+1 for hi-byte of a word.
01:6079 B5 F8 lda <__ax, x ; Force zero-page mode. 01:607B B5 F8 lda.l <__ax, x ; Addr+0 for lo-byte of a word. 01:607D B5 F9 lda.h <__ax, x ; Addr+1 for hi-byte of a word.
01:607F BD F8 20 lda __ax, x ; Default is absolute mode. 01:6082 BD F8 20 lda.a __ax, x ; Force absolute mode (redundant). 01:6085 B5 F8 lda.z __ax, x ; Force zero-page mode.
; **************************************************************************** ; ; C-style line and block comments are available in KickC mode ... ; ; This is not a true pre-processor, it is line oriented, and so it ; can only handle block comments at the beginning and end of lines. ;
.kickc ; Switch to KickC mode
01:6087 82 clear_bat: clx // Offset to PCE VDC.
/* ** Block comments are OK. ** 01:6088 64 F0 */ stz.z __di + 0 /* Set VDC or SGX destination 01:608A 64 F1 */ stz.z __di + 1 /* address. */ 01:608C 20 38 E1 jsr __di_to_vram
// lda.z __bl // Xvert hi-byte of # words 01:608F 4A lsr // in screen to loop count.
01:6090 C2 cly 01:6091 48 .bat_loop: pha 01:6092 A5 F8 lda.z __ax + 0 /* Redundant */ /* comment */ 01:6094 9D 02 00 sta VDC_DL, x 01:6097 A5 F9 lda.z __ax + 1 01:6099 9D 03 00 .bat_pair: sta VDC_DH, x /* Write 1st word. */ 01:609C 9D 03 00 sta VDC_DH, x // Write 2nd word. 01:609F 88 dey 01:60A0 D0 F7 bne .bat_pair /* pla // In block comment, so do */ 01:60A2 3A dec // Line comment, so ignore /* 01:60A3 D0 EC bne .bat_loop
01:60A5 60 /* Why??? */ rts // Because we can!
; **************************************************************************** ; ; Traditional 6502 assembler usage of '()' for indirect addressing is now ; supported, but only in KickC mode, because it can change the meaning ... ;
.kickc ; Switch to KickC mode
01:60A6 B1 F8 lda (__ax),y ; Indirect addressing 01:60A8 B1 F8 lda [__ax],y ; Indirect addressing
.pceas ; Switch to PCEAS mode
01:60AA B9 F8 20 lda (__ax),y ; Absolute addressing 01:60AD B1 F8 lda [__ax],y ; Indirect addressing
|
|
|
Post by dshadoff on Dec 7, 2021 1:15:19 GMT
Very interesting.
OK, I have a series of questions: 1) How many encodings are you planning to support ? SJIS at least ?
2) I see the "jmp !skip-" jumps to the same line, which seems a bit odd to me (I would have though it would go back prior to the current opcode's label; that "jmp !skip" - no minus - would be for the current one). Was this intentional ?
3) Wasn't the 'a' for accumulator optional previously ? I thought it was...
4) How about TMA - are we able to use both TAM0 and TAM #1 syntax ?
Now, comments: 1) In practice, I don't see any reason for the { } syntax, as all of that can be done with the '.' syntax. But I also see no reason to argue about it.
2) I like the label.sublabel syntax; I'm not sure if it was available previously, but I would much more likely use that.
3) Wow, I didn't know that there were .h and .l suffixes for opcodes... and thank you for the "force absolute" and "force ZP", although I woudl have always used "<" to force ZP, and assumed that absolute was the case in all other contexts... although occasionally I'd miss an opportunity for ZP usage.
4) Not a big fan of the "#>__ax ; One method to get hi-byte." syntax. I think those are backward, but I'd never use them anyway.
Right now, perhaps one of the more useful things which could be added (but I know it would be challenging) would be to apply output to an arbitrary binary file. In other words, the assembly output would apply to a ROM or CD DATA MODE1/2048 file similarly to how an IPS file would.
This can currently be done to a small enough ROM file by ".incbin" directly, and assembling on top of those banks... ...But for CDROM binaries, they are too large, so the key banks need to be extracted and re-implanted with external utilities.
Just a thought.
|
|
|
Post by turboxray on Dec 7, 2021 1:45:01 GMT
The {} was something MooZ and I had talked about recently, to add to PCEAS. That's a VERY welcome feature haha. I usually do this manually with equates to translate the local scopes labels into name.<label> format. It should be usable for ram (bss/zp areas) for creating data structures.
lda.a, lda.z, lda.h, etc should be macros. I don't think they need to be assembler pseudo instructions.
01:6044 FF FF FF FF ds 8,255 ; <-- new syntax! ^ I'm a little leery of this. If it's for rom, does the directive need to be named "ds"? Why not "rep"?
Is .const and .label needed for kickc or something else? Or is this just for clarity or something?
We need more than one .rs counter too. Maybe make a label definable as a unique counter.
|
|
|
Post by elmer on Dec 7, 2021 2:49:46 GMT
Hi Dave! 1) How many encodings are you planning to support ? SJIS at least ? I'm not personally planning on implementing *any* encodings other than the default ASCII at the moment ... but UTF8-to-SJIS is an encoding that I think would be useful for PCE developers. It is there now just so that some existing source-code doesn't break. 2) I see the "jmp !skip-" jumps to the same line, which seems a bit odd to me (I would have though it would go back prior to the current opcode's label; that "jmp !skip" - no minus - would be for the current one). Was this intentional ? Absolutely intentional, I'm afraid. Was the label located before the jump on that line of text? "Yes", so that is the way that the syntax currently works, just as it is defined by the assembler that I'm trying to achieve compatibility with. That doesn't mean that I don't agree that your thinking is better ... but it doesn't match up with the syntax that I'm copying. 3) Wasn't the 'a' for accumulator optional previously ? I thought it was... Hahaha .. "Yes" it was. I guess that I'll remove the code that I added! 4) How about TMA - are we able to use both TAM0 and TAM #1 syntax ? This has been in PCEAS for years, but since PCEAS uses TMA #(0-7) instead of TMA #($00-$FF), I've always used the TAMn syntax. 1) In practice, I don't see any reason for the { } syntax, as all of that can be done with the '.' syntax. But I also see no reason to argue about it. No, it really can't ... the '.' local variables are not available in global scope, while the "{}" scoped variables are. What you're saying makes sense for sourcecode that is written to use local variables, but this feature wasn't added for that kind of sourcecode. 2) I like the label.sublabel syntax; I'm not sure if it was available previously, but I would much more likely use that. Now you're confusing me ... the label.sublabel syntax needs *some* way of scoping when you use it, and when you don't. I have a hard time understanding how you can do (2) without some kind of (1) ... and again, this specific implementation of (1), i.e. the "{}" is all about compatibility. 3) Wow, I didn't know that there were .h and .l suffixes for opcodes... and thank you for the "force absolute" and "force ZP", although I woudl have always used "<" to force ZP, and assumed that absolute was the case in all other contexts... although occasionally I'd miss an opportunity for ZP usage. Honestly, I think that all instruction suffixes, including ".z" and ".a", are absolute abominations! But, I needed ".z" and ".a" for compatibility, and some poor perverted soul, now cursed-forever to program only in ADA, put those suffixes in way back before PCEAS v3.21, and that did make my task much easier. 4) Not a big fan of the "#>__ax ; One method to get hi-byte." syntax. I think those are backward, but I'd never use them anyway. Hahaha ... that syntax has been in since at-least PCEAS v2.51, so I think that the statute-of-limitations has run out on complaints! Personally, I use '<' and '>' exclusively, and never "LOW()" or "HIGH()" ... I've been using that '<' and '>' syntax for 6502 code since the 1980s!
|
|
|
Post by elmer on Dec 7, 2021 3:12:17 GMT
The {} was something MooZ and I had talked about recently, to add to PCEAS. That's a VERY welcome feature haha. I usually do this manually with equates to translate the local scopes labels into name.<label> format. It should be usable for ram (bss/zp areas) for creating data structures. I'm glad that you'll both find it useful! I think that I've currently got it limited to the "code" section, but that can easily be changed once I've confirmed how KickC is using it. lda.a, lda.z, lda.h, etc should be macros. I don't think they need to be assembler pseudo instructions. I'm not saying that you're wrong ... but the ".l" and ".h" were already implemented in PCEAS, so it made sense to piggyback off the existing functionality. 01:6044 FF FF FF FF ds 8,255 ; <-- new syntax! ^ I'm a little leery of this. If it's for rom, does the directive need to be named "ds"? Why not "rep"? It doesn't *need* to be ".ds", but I am familiar with the ".ds <count>,<value>" syntax from many other assemblers, and so when I needed to add ".fill <count>,<value>", it just made sense to extend the existing ".ds", which didn't previously allow a 2nd parameter, and so no existing code would break. Is .const and .label needed for kickc or something else? Or is this just for clarity or something? It's ugly, isn't it! Yeah, it's just there for KickC (i.e. KickAssembler) compatibility. We need more than one .rs counter too. Maybe make a label definable as a unique counter. Yes, we do, and that is one good solution! Or something as simple as a ".set" directive that doesn't give errors if the label is already defined. The capability is needed, but I'm afraid that it just isn't at the top of my priority list right now. Maybe soon.
|
|
|
Post by dshadoff on Dec 7, 2021 4:03:52 GMT
This has been in PCEAS for years, but since PCEAS uses TMA #(0-7) instead of TMA #($00-$FF), I've always used the TAMn syntax. Oh, I wasn't aware that PCEAS processes the TAMn syntax. That was really what I was asking. 2) I like the label.sublabel syntax; I'm not sure if it was available previously, but I would much more likely use that. Now you're confusing me ... the label.sublabel syntax needs *some* way of scoping when you use it, and when you don't. I have a hard time understanding how you can do (2) without some kind of (1) ... and again, this specific implementation of (1), i.e. the "{}" is all about compatibility. I understand that this is how the assembler needs to internally track the names - I just wasn't aware that it could be referenced by the user/source code in this way. 4) Not a big fan of the "#>__ax ; One method to get hi-byte." syntax. I think those are backward, but I'd never use them anyway. Hahaha ... that syntax has been in since at-least PCEAS v2.51, so I think that the statute-of-limitations has run out on complaints! Personally, I use '<' and '>' exclusively, and never "LOW()" or "HIGH()" ... I've been using that '<' and '>' syntax for 6502 code since the 1980s! Wow. I had no idea. It wasn't in the documentation, and I guess I never dug into that section of the code either...
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Dec 7, 2021 8:48:57 GMT
Did you want the '@' character to be usable anywhere within any kind of label, or was the idea to just use '@' as an alternative to '.' at the start of a label to signify local labels? I ask because the checkin comment implies the 2nd case, but the way that it is implemented results in the 1st case. '@' was meant to be used for "local" labels (just like '.' prefixed ones). It was in an attempt to make it compatible with ca65.
|
|
|
Post by elmer on Dec 7, 2021 15:09:46 GMT
'@' was meant to be used for "local" labels (just like '.' prefixed ones). OK, thanks! I have changed the behavior in PCEAS so that '@' is only allowed in a label if it is at the beginning (just like CA65). We need more than one .rs counter too. Maybe make a label definable as a unique counter. Yes, we do, and that is one good solution! Or something as simple as a ".set" directive that doesn't give errors if the label is already defined. The capability is needed, but I'm afraid that it just isn't at the top of my priority list right now. Maybe soon. Well, I changed my mind once I realized just how easy it would be to implement. So I have added ... 0003 mycounter .set 3 ; ".set" allows a label to change 0004 mycounter .set mycounter + 1 0006 mycounter .set mycounter + 2
0008 .var mycounter = 8 ; So does ".var"
The ".set" syntax is what is used by CA65, and many other assemblers that I am familiar with, and the ".var" syntax is from KickAssembler (which does many weird things, but at least it doesn't usually conflict with existing PCEAS syntax). Unfortunately, I can't add "set" as an alternative for the ".set" pseudo-op, because "set" is an instruction. Which brings up the question of why are there all the "without-a-dot" pseudo-ops in PCEAS? ... But I guess that it's both far-too-late to change that now, and I really like having some of them, so I'm terribly conflicted on the issue of whether they're a good idea or not.
|
|