Created attachment 170 [details] Test program which creates two identical byte arrays Build the attached program with rmac. It will fail due to an assertion failure because the two should-be-identical byte arrays are not in fact compiled to identical data. Looking at the raw content of the output, the array defined using dc.b is correct, while the array defined using dc.s is not. MADMAC v3.03 compiles both correctly.
Hi there, I've tried searching around for this, but what type does madmac process with ".s"? Up till now I've never even seen that being used, nor was it ever a part of smac (if memory serves). So I've used it for representing 68k FPU single precision floating point numbers. Without even looking at the source, passing a string as a float was never tested. Nor I have a good idea what the assembler should do about it.
It's a byte. Quoting the rmac manual, the "Directives" section: http://rmac.is-slick.com/manual/rmac.html#directives "Some directives accept size suffixes (.b, .s, .w or .1); the default is word (.w) if no size is specified. The .s suffix is identical to .b."
I should note: I ran into this while building the Atari Memory Track ROM source with rmac, as detailed in a very long post in the "Smelly Adventures" thread on the AtariAge Jaguar forums a few days ago.
Created attachment 176 [details] Clarification in the docs Ok, I tried to fix this, but it's much harder than it looks. So I tried to add some logic that hands the constant over to the dc.b handler if no float is detected. But then, what does "dc.s 0" do? If we assume it's byte 0 then this starts to break hundreds of 68881/2 code that assumes that dc.s is actually a float. So nope, I'm afraid I'll fold on this one. I added a patch to update the documentation but I'm afraid that's all that'll happen here.
That's fine by me. I moved to dc.b and all is well, and this is also the first time I've encountered the 's' size specifier, so it must be pretty out of favor. The doc update LGTM.
Patch has been added. :-)