!!! absolute addressing is not used for word-sized labels when .w suffix is not present on RAMSECTION labels (linker error)

[bazz1tv]

Yes this is a repeat post of a sub-comment in #34 but they are truly separate issues. Ville pointed out in the issue linked (34) that word addressing should automatically be used if the byte addressing fails. Well for my project (huc6280) any label that is word-sized never links successfully, if .w is not used explicitly. It's really annoying, I hope to fix this bug with you WLA DX developer(s). Let's do this together.

here's what happens when trying to link main.o compiled from wla-huc6280:

FIX_REFERENCES: Value ($2215) of "bg_start_tilenum" is too much to be a 8bit value.
this error references the line
sta bg_start_tilenum
which is a RAMSECTION label that references a slot of $2000 start addr. So far I've had to manually append .w to all my word-size labels.

This is a high priority issue. Here's why, from my experiences

• forces the creation of separate macros for zero-page/abs addressing -- this can get worse when each separate argument could be any combination of ZP/abs addressing -- and you can imagine it gets worse from there when the number of macros is increased with the fact that I'm porting code where this automation is expected to be functioning already.
• Cannot automatically migrate variables between zero-page and absolute RAM address range [in the case that a variable would need to be migrated, all references to it would need to be modified to remove the .w suffix]

[bazz1tv]

relevant file:line# == write.c:795

Ville/someone-skilled-in-WLA I don't know if you're looking into this issue, so I'll try to do what I can and post hints as I learn.

If someone doesn't have time to look into this, can they enlighten me what I'm looking for?? -- I took a look at the source and I'm clueless blink blink blink

[bazz1tv]

I have discovered that this is ONLY the case with RAMSECTION labels and NOT .ENUM variables

[bazz1tv]

bug_exhibition code example [I used huc6280, but I think it might be applicable to others]: http://botb.club/~bazz/wladx/issue53.zip [includes makefile/linkfile]

;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
; a small example showing the wla 65c02 syntax
; written by ville helin <vhelin@cc.hut.fi> in 2002
;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»

.MEMORYMAP
DEFAULTSLOT 0
SLOTSIZE $2000
SLOT 0 $0000
SLOT 1 $2000
SLOT 2 $4000
SLOT 3 $6000
SLOT 4 $A000
.ENDME

.ROMBANKMAP
BANKSTOTAL 4
BANKSIZE $2000
BANKS 4
.ENDRO

;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
; main
;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
.ramsection "vars" bank 0 slot 1
derp dw
.ends

.bank 0 slot 0
.org 0
.section "code"
    lda derp
.ends

[vhelin]

Ah yes, this one. This is one of the bigger "problems" with the architecture of WLA DX; as the labels ("derp" in this case) are placed into the output in the linking phase, the assembler has no idea what the value of the label is going to be at the assembling stage, so it chooses the smallest argument size by default... You can give the assembler a hint about the size using .16BIT or .w, for example...

This could be fixed by defaulting to 16bit values, as I guess they are more probable than 8bit values, when labels are considered, but fixing it would take time and a lot of changes in the code. We could make it so that all labels are 16bit by default, in cases like this, and pending computations 8bit by default, but that might confuse the users even more.. I guess the probability of a pending calculation being 8bit is bigger than being 16bit in the context of WLA-DX.

I'm not going to touch this issue at this point as it would be a big change. Instead I'll fix the other smaller ones, and think about this mean while... If there was an easy way to make this better...

[bazz1tv]

I have an assortment of responses and ideas.

If there was an easy way to make this better

My whole reasoning for using RAMSECTION is having a way to automatically manage memory assignment across my project. Since .ENUM definitions work fine -- they can be used without .w, Is it possible to easily have ramsections act as definitions instead of labels? It could be implemented as an additional option. Tell me all about it.

----- further ideas don't read

.16BIT - There is a lot of calamity in the usage of this directive, my instinct tells me. There's too many issues in my mind overwhelming me to put it all into words. But here are some concerns in an emoticon: :O

For instance:

LSR 11       ; $46 $0B

that would be the case, normally, but after .16BIT it becomes

LSR 11       ; $4E $0B $00

Thoughts:
would LSR 11.b prevent from 16-bit expansion (in a general context non-huc6280)?

I wonder what other opcodes will become something I do not expect??

Can I use <label to escape the 16-bit default?

The whole point of all this is I want to see WLA DX be able to have generic macros like it ought to .. so that one macro can be used on zero-page labels, abs labels, and immediate values. I'm still not exactly sure how we'll arrive there, but that's the goal. If I use .16BIT I'll probably have to make sure I pass as arguments to the macros <label for ZP, label.w (thanks to issue.. erm lost my train of thought)

I can create tests for these concerns..

[bazz1tv]

bug_exhibition test for use when issue 52/53 are solved : http://botb.club/~bazz/wladx/generic_macro_test.zip

[bazz1tv]

Good luck bug fixing. I hope that you take care of it.

[bazz1tv]

This should be a bug not an enhancement

[nicklausw]

I'm not really sure if it should be considered a bug. It isn't a problem in the existing code, it's something that needs to be implemented; WLA isn't designed to calculate 8-bit vs 16-bit in the first place.

The way this is handled varies based on the assembler.

• ca65 defaults to 16 bit, makes you implicitly state that something is zeropage (no direct page supported). All foreign symbols need to be imported, and you must describe their value properly.
• asm6 keeps on looping through the code until it figures out the size. Always defaults to zeropage when possible. (no linker stage)
• nesasm makes you give implicit values for everything (no linker stage)
• bass and xkas make you tell them the opcode size. (no linker stage)

wla-dx defaults to 8-bit and never makes the user state which opcode to use for certain defines/labels; you always need to use .b, .w, .l.

The best temporary solution that I see fit is to default to 16-bit. The more complex solution that I want is for the assembler to determine a value for every bank/slot. This slot only accesses 8-bit values? Mark it as zeropage. This one only accesses 16-bit values? Absolute. Both? Default to absolute to avoid errors.

I don't really know how to tell the assembler the opcode size of symbols from other modules. Could add a system of import and export but that wouldn't really fit well with the rest of the program. I don't know how else it could be done.

[nicklausw]

Maybe there can be a new 'mode' in WLA, specified through the command line arguments that doesn't turn foreign symbols into pending calculations, and instead spits an error, forcing you to import the symbol? I'm thinking we just have a 'global' directive, rather than import and export, because then there's the need to modify the linker in painful ways to manage all that.

[bazz1tv]

I don't want to argue about whether this a bug or enhancement, so let's go down to that exact issue I face.

I'm having trouble relating to you because WLA-DX already has a level of implicit interpreting.

16-bit ENUM definitions can already be implicitly understood.

bug_exhibition - 65816 - main.s

;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
; a small example showing the wla 65816 syntax
; written by bazz 2016
;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»

.MEMORYMAP
DEFAULTSLOT 0
SLOTSIZE $2000
SLOT 0 $0000
SLOT 1 $2000
SLOT 2 $4000
SLOT 3 $6000
SLOT 4 $A000
.ENDME

.ROMBANKMAP
BANKSTOTAL 4
BANKSIZE $2000
BANKS 4
.ENDRO


;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»
; main
;»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»

.ENUM $1000
derp db
.ENDE

.bank 0 slot 0
main:
    lda derp

---

But, a 16-bit RAMSECTION label is not implicitly understood. bug_exhibition code

Example error msg:
FIX_REFERENCES: Value ($2215) of "bg_start_tilenum" is too much to be a 8bit value.

---

I migrated from ENUM to RAMSECTION for its automatic management across source files, but not to get a dumber sense of inference. I don't know why it is this way.

We know that ENUM produces definitions which are inferred (apparently) properly, but RAMSECTION produces labels that are not. If there's not a good reason for this, why is it being done?

One of my last suggestions was never responded to, but I think it may be a good temporary solution. Ideally though, we need @vhelin who truly knows of the proper solution(s) because he knows the code so well. Here is my suggestion again

Since .ENUM definitions work fine -- they can be used without .w, Is it possible to easily have ramsections act as definitions instead of labels? It could be implemented as an additional option.

[nicklausw]

Definitions can only be made when the final value is known.

A ramsection is still a section; its placement isn't actually calculated until the linker stage. Therefore ramsections cannot place symbols into defines, because there isn't a real value yet. If it functioned just like an enum, then there really wouldn't be a point to having it.

So this is why I think it'd be a good idea for slots to automatically be given sizes. As I said, if it's in the slot that only reaches 8-bit values, then it's 8-bit (zeropage), and so use the proper opcode for that. This would fix most situations just fine if you're using a single module (object).

[bazz1tv]

I understand your reasoning and I like your solution, but for a point of understanding - who can explain

why are labels forcibly interpreted as 8-bit

I don't see why labels being at the linker stage equates to "must force infer as 8-bit" -- especially when we have an error message that shows the system has grasp of a 16-bit value, which itself could be used to infer 16-bits

[nicklausw]

The linker doesn't see the opcode lists at all, just the opcode number and whether it can support 16-bit; it can't come up with alternatives because it doesn't know any. Doesn't the assembler default all labels to 8-bit? I don't think ramsections are any special exception.

[bazz1tv]

Gotcha.. So now I'm just wondering if implementing your slot idea the best step forward? Or, is the architecture of WLA-DX at fault here? In other words, is it bad design that the assembler builds objects like this where the linker then has not much idea what to do in this case? I'm very much concerned over the architecture of WLA-DX, but I don't know enough about it to get started yet.

[bazz1tv]

We could make it so that all labels are 16bit by default, in cases like this, and pending computations 8bit by default, but that might confuse the users even more.. I guess the probability of a pending calculation being 8bit is bigger than being 16bit in the context of WLA-DX.

Ville, how hard would it be to make this alteration? I'd like to try it out and see if it feels "natural" for my use cases (typically huc6280, 65816, spc700)

[vhelin]

It took me a few years, but does the recent commit (-h flag) fix this issue? :D

PS. Sorry for taking so long, old issues just got buried under new ones...