Bug 198 - dc.s is broken
Summary: dc.s is broken
Alias: None
Product: RMAC
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC Linux
: Normal enhancement
Assignee: Shamus Hammons
Depends on:
Reported: 2022-04-16 23:36 CDT by James Jones
Modified: 2022-05-30 12:23 CDT (History)
2 users (show)

See Also:

Test program which creates two identical byte arrays (238 bytes, application/octet-stream)
2022-04-16 23:36 CDT, James Jones
Clarification in the docs (1.38 KB, patch)
2022-04-17 04:45 CDT, ggn

Note You need to log in before you can comment on or make changes to this bug.
Description James Jones 2022-04-16 23:36:03 CDT
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.
Comment 1 ggn 2022-04-17 00:44:02 CDT
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.
Comment 2 James Jones 2022-04-17 01:32:25 CDT
It's a byte. Quoting the rmac manual, the "Directives" section:


"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."
Comment 3 James Jones 2022-04-17 01:35:04 CDT
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.
Comment 4 ggn 2022-04-17 04:45:30 CDT
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.
Comment 5 James Jones 2022-04-17 23:35:38 CDT
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.
Comment 6 Shamus Hammons 2022-05-30 12:23:52 CDT
Patch has been added.  :-)