Closed vhelin closed 3 years ago
WDC 65816 is 16-bit- just has an 8-bit external bus. Maybe 68k support might be useful at some point if WLA internally can support a 24-bit address space.
.DL and .DD would be useful for those two archs.
Well, let's leave this enhancement to that day someone wants to add support for 68k/similar CPUs. :) (I just moved this enhancement from that old TODO-file to here, GitHub, so I could delete the file).
On Sun, Nov 30, 2014 at 6:06 PM, William D. Jones notifications@github.com wrote:
WDC 65816 is 16-bit- just has an 8-bit external bus. Maybe 68k support might be useful at some point if WLA internally can support a 24-bit address space.
.DL and .DD would be useful for those two archs.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/22#issuecomment-64989859.
Without knowing offhand- does WLA internally represent a CPU's memory map in 16 bits (minimum size promised by short/int) or 32 bits (minimum size promised by long)? Or is there no practical limit thanks to .SLOTS?
In Zexall I'm defining 32-bit numbers via a macro:
.macro CRC
.db (\1>>24)&$ff,(\1>>16)&$ff,(\1>>8)&$ff,\1&$ff
.endm
So .dd would make it slightly less ugly, although the CRC macro remains useful for making the intent clear.
On Sun, Nov 30, 2014 at 6:35 PM, William D. Jones notifications@github.com wrote:
Without knowing offhand- does WLA internally represent a CPU's memory map in 16 bits (minimum size promised by short/int) or 32 bits (minimum size promised by long)? Or is there no practical limit thanks to .SLOTS?
I think there is no limit, thanks to .SLOTS... :) Or wait, currently there are max 256 slots, and each has 2GB limit -> 256*2GB might be the limit for the memory space? :) Of course the addresses get capped at $ffff in output, because the supported CPU architectures don't support more, but internally in WLA there should be no limit.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/22#issuecomment-64990720.
On Mon, Dec 1, 2014 at 6:37 PM, Maxim notifications@github.com wrote:
In Zexall http://www.smspower.org/Homebrew/ZEXALL-SMS I'm defining 32-bit numbers via a macro:
.macro CRC .db (\1>>24)&$ff,(\1>>16)&$ff,(\1>>8)&$ff,\1&$ff .endm
So .dd would make it slightly less ugly, although the CRC macro remains useful for making the intent clear.
Cool, so there might be demand, albeit small, for .dl and .dd. There is no way for people to give votes to enhancement suggestions in GitHub? :) It'd be great if people could vote for features they think would be useful...
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/22#issuecomment-65092612.
Hey, what about support for
.d8 (same as .db) .d16 (same as .dw) .d24 (three bytes) .d32 (four bytes)
??? That would make things simple and clear...
My only complaint with that is it isn't universal. It'd be a nice alias to the existing db and dw though.
.dl and .dd are more universal. However, .d8-.d64 could certainly alias.
I operate under the assumption that code written in WLA is not going to be compatible with other assemblers*, but might as well try to make it as painless as possible.
*Which is part of the reason I think it's so important that the code base is portable- code parsed by WLA may not be portable to other assemblers, but at least WLA can be compiled on basically any hosted system with an ANSI C Compiler, so ppl aren't SOL if they want to work with existing WLA asm code.
Forgot to mention this issue in the commit, but ea7f00b7bd054eb7308fb43db41f7794807e8a5f ( https://github.com/vhelin/wla-dx/commit/ea7f00b7bd054eb7308fb43db41f7794807e8a5f ) added support for 32-bit .DD, DSD and DDM, which should fix this issue.
.DL = define long word .DD = define double long word
Is there any need for these as the currently supported CPUs are all 8bit?