ggn Posted June 27, 2022 Share Posted June 27, 2022 http://rmac.is-slick.com/index.html#rmac-2-2-4 v2.2.4 is now a thing. Thanks to everyone contributing patches and bug reports, they're all welcome! Small list of changes since last release: PC relative fixups in TOS mode were missing range check. This has been fixed PACK and UNPACK GPU RISC instructions are swapped Minor fix to kill unnecessary field YPOS in gpuobj in the OP assembler Added -4 switch that enables C style operator precedence. Consult the manual for a more thorough description of this switch Download and enjoy! 3 Quote Link to comment Share on other sites More sharing options...
ggn Posted June 27, 2022 Share Posted June 27, 2022 4 hours ago, 42bs said: One more: .align <alignment> For example: .align 12 or .align 128 align.patch 1.95 kB · 1 download Thanks for this @42bs! I'll do some checks with 56001 mode, see that nothing bad breaks there. Otherwise it looks good! Quote Link to comment Share on other sites More sharing options...
ggn Posted August 16, 2022 Share Posted August 16, 2022 The people have asked (and also did the work!), so we deliver! rmac v2.2.7 and rln v1.7.4 are now out! http://rmac.is-slick.com/index.html#rmac-2-2-7 The list of changes: rmac Added stabs symbol factory support Added support for -g debug info generation Introduced .align directive Fixed .ccdef, broken since v2.2.2 rln Handle absolute BSS segment location of xt switch Added Alcyon C object file support Increased number of maximum command line arguments allowed Increased number of maximum symbols handled Thanks to @cubanismo and @42bs for doing most of the work on this release! Myself and @Shamus mostly sat back and applied the patches people gave us. For reference, here's @42bs' contribution: And of course the tour-de-force @cubanismo submitted which enables debugging symbols for his project seen here: Also thanks to @JagMod for reporting some issues (which I took an embarrassingly long time to get round to fixing). That said, at least it's out, you're very welcome to download a binary from our website, or build from source. Enjoy! 2 4 Quote Link to comment Share on other sites More sharing options...
Ericde45 Posted September 27, 2022 Share Posted September 27, 2022 (edited) hello it seems i met a bug in rmac here is a sample code : move.l #silence,d1 move.l #silence<<11,d0 lsl.l #8,d1 lsl.l #3,d1 here is the result in debugger: 04000: 223C00005C08 move d1, #5C08 004006: 203C00009C00 move d0, #9C00 00400C: E189 lsl d1, 8 00400E: E789 lsl d1, 3 << seems to stop at 8 like lsl in 68000 if it is done on purpose, this should be in the documentation in bold on for example #8000<11 i get the right value : move.l #(8000<<11),d2 0400C: 243C00FA0000 move d2, #FA0000 it seems linked to the use of a label Edited September 27, 2022 by Ericde45 Quote Link to comment Share on other sites More sharing options...
42bs Posted September 27, 2022 Share Posted September 27, 2022 (edited) I checked the latest rmac and get: I tried both a symbol and direct, but not a code label. Edited September 27, 2022 by 42bs Quote Link to comment Share on other sites More sharing options...
42bs Posted September 27, 2022 Share Posted September 27, 2022 (edited) Yep, it is a bug: move.l #memcpy,d0 move.l #memcpy<<2,d1 move.l #memcpy<<4,d1 move.l #memcpy<<8,d1 move.l #memcpy<<10,d1 becomes: Edited September 27, 2022 by 42bs Quote Link to comment Share on other sites More sharing options...
42bs Posted September 27, 2022 Share Posted September 27, 2022 Ah, ok, it is a limitation of "rln". Code labels are link-time defined, and I am pretty sure COF does not provide complex arithmetic on those. Often adding or subtracting is possible. But I think not even masking. Even ELF does not allow logic operations. 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted September 27, 2022 Share Posted September 27, 2022 Reported in March - apparently latest RMAC rejects it with an error. Quote Link to comment Share on other sites More sharing options...
42bs Posted September 27, 2022 Share Posted September 27, 2022 (edited) 56 minutes ago, Ericde45 said: here is a sample code : move.l #silence,d1 move.l #silence<<11,d0 lsl.l #8,d1 lsl.l #3,d1 I'd do swap d1 lsr.l #5,d1 Edited September 27, 2022 by 42bs Quote Link to comment Share on other sites More sharing options...
Ericde45 Posted September 27, 2022 Share Posted September 27, 2022 (edited) 1 hour ago, 42bs said: I'd do swap d1 lsr.l #5,d1 good advice ! ( precalculating with <<11 in source would even be faster ) and even better with ror.l #5,d1 for 32 bits addresses Edited September 27, 2022 by Ericde45 Quote Link to comment Share on other sites More sharing options...
42bs Posted September 27, 2022 Share Posted September 27, 2022 1 hour ago, Ericde45 said: good advice ! ( precalculating with <<11 in source would even be faster ) and even better with ror.l #5,d1 for 32 bits addresses If you can avoid it as code label but define, it should work. Quote Link to comment Share on other sites More sharing options...
ggn Posted September 27, 2022 Share Posted September 27, 2022 (edited) Thanks to everyone for replying faster than me! Basically it's what @42bs said, you can't pass complex expressions to the linker. Its job is mostly plugging in some values that the assembler/compiler left out because it didn't know at the time. If you absolutely need your code to work (cricial code), you could supply the constant inside the same source file: silence=8000 move.l #silence,d1 move.l #silence<<11,d0 lsl.l #8,d1 lsl.l #3,d1 (of course you can put the definition of "silence" below the code, it doesn't matter as long as it's in the same file or included file) Having said all this, we can do better. We should add some checks against this behaviour, so people don't get blown in the face. We do have some code that disallows PC relative access between different object files (for obvious reasons), we could add something that errors out if a symbol is used in an expression and it's not resolved at the end of assembly. I'll add an issue for this. (EDIT: Issue #209) Edited September 27, 2022 by ggn 2 Quote Link to comment Share on other sites More sharing options...
ggn Posted October 17, 2022 Share Posted October 17, 2022 (edited) I guess most people don't care (none?), but there is now a candidate fix for the above issue here. It should be applied shortly! (provided we don't find any other side effects) Edited October 18, 2022 by ggn I can't English 2 5 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 17, 2022 Share Posted December 17, 2022 Fixed an issue when running rmac on M1 Mac, see my fork. There is also an issue regarding float support (likely not for Jaguar/6502 programming ). Quote Link to comment Share on other sites More sharing options...
ggn Posted December 17, 2022 Share Posted December 17, 2022 7 hours ago, 42bs said: Fixed an issue when running rmac on M1 Mac, see my fork. Thanks, will take a look and probably release a new version with some other fixes as well! 7 hours ago, 42bs said: There is also an issue regarding float support (likely not for Jaguar/6502 programming ). Maybe not now but maybe if we implement http://jlhconsulting.gotdns.com/bugs/show_bug.cgi?id=141 it's not impossible 2 Quote Link to comment Share on other sites More sharing options...
Shamus Posted December 22, 2022 Share Posted December 22, 2022 rmac 2.2.14 is coming 4 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 24, 2022 Share Posted December 24, 2022 I see that Santa @Shamus spilled the beans already :D. Might as well then! rmac v2.2.14 is now out! http://rmac.is-slick.com/#rmac-2-2-14 Here's the list of changes: Fix for some rare cases that would trigger an error in code inside a disabled block Fixed a few bugs in .incbin optional parameters Fixed a long standing 680x0 parsing issue where an expression like “lea (4*8)+2(a0),a1” would produce a syntax error Added support for Commodore 64 .PRG output format (-fc) Added guard against exporting fixups that are used as a part of an expression Added support for -fr switch and 6502 mode Fixed a bug in floating point number parsing Fixed a bug where very long filenames would cause a crash Many thanks to all the people who reported bugs or even contributed fixes. And, of course, Merry Christmas and a Happy New Year to everyone! 5 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 24, 2022 Share Posted December 24, 2022 1 hour ago, ggn said: I see that Santa @Shamus spilled the beans already :D. Might as well then! rmac v2.2.14 is now out! http://rmac.is-slick.com/#rmac-2-2-14 Here's the list of changes: Fix for some rare cases that would trigger an error in code inside a disabled block Fixed a few bugs in .incbin optional parameters Fixed a long standing 680x0 parsing issue where an expression like “lea (4*8)+2(a0),a1” would produce a syntax error Added support for Commodore 64 .PRG output format (-fc) Added guard against exporting fixups that are used as a part of an expression Added support for -fr switch and 6502 mode Fixed a bug in floating point number parsing Fixed a bug where very long filenames would cause a crash Many thanks to all the people who reported bugs or even contributed fixes. And, of course, Merry Christmas and a Happy New Year to everyone! There is a small bug in direct.c IIRC: a * is missing. Fixed in my version. Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted January 14, 2023 Share Posted January 14, 2023 On 9/27/2022 at 1:20 PM, ggn said: we could add something that errors out if a symbol is used in an expression and it's not resolved at the end of assembly. I'll add an issue for this. (EDIT: Issue #209) Note this broke stuff. As @42bs noted, basic integer addition and subtraction work fine in this regard, and there's code that relies on this. Issue #218 filed. I think I can construct a patch that hides the error in this case, but it's really hacky. I initially started writing a patch that strictly fails arithmetic operations that don't work on undefined symbols when an external symbol is involved within the expression evaluator itself, but after perusing other uses of the expression evaluator to see if that would break anything, it looks like there are currently dozens of uses that just soldier on when performing unsupported arithmetic on undefined values. I don't have time to go and walk through them all to see if they should be fixed or left as-is, so I gave up. Unless someone else wants to tackle that, I'd suggest just reverting the new error, given it's likely a very partial fix anyway. Quote Link to comment Share on other sites More sharing options...
ggn Posted January 14, 2023 Share Posted January 14, 2023 10 hours ago, cubanismo said: Note this broke stuff. As @42bs noted, basic integer addition and subtraction work fine in this regard, and there's code that relies on this. Issue #218 filed. I think I can construct a patch that hides the error in this case, but it's really hacky. I initially started writing a patch that strictly fails arithmetic operations that don't work on undefined symbols when an external symbol is involved within the expression evaluator itself, but after perusing other uses of the expression evaluator to see if that would break anything, it looks like there are currently dozens of uses that just soldier on when performing unsupported arithmetic on undefined values. I don't have time to go and walk through them all to see if they should be fixed or left as-is, so I gave up. Unless someone else wants to tackle that, I'd suggest just reverting the new error, given it's likely a very partial fix anyway. Thanks for the heads up. I shall look into this soon (and I really ought to make a note of adding the 3D library in the regression tests). 2 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted January 14, 2023 Share Posted January 14, 2023 1 minute ago, ggn said: and I really ought to make a note of adding the 3D library in the regression tests I considered suggesting that, but note it contains a lot of C code and stuff too, so you need to have a mildly complex environment set up to build it fully. If you just want RMAC tests though, you could pull out all the assembly files and verify they at least parse or do before/after object file comparisons. Quote Link to comment Share on other sites More sharing options...
ggn Posted January 14, 2023 Share Posted January 14, 2023 4 minutes ago, cubanismo said: I considered suggesting that, but note it contains a lot of C code and stuff too, so you need to have a mildly complex environment set up to build it fully. If you just want RMAC tests though, you could pull out all the assembly files and verify they at least parse or do before/after object file comparisons. That's exactly what we do: for large projects we just assemble all the things we want to test, and keep reference binaries to check against the newer built files. This way we don't drop compatibility (or at least try to!) Anyway, sorry for making you waste more time with this update :(. And really you shouldn't waste even more time trying to fix things, just shout at us and we'll fix it (since we broke it in the first place!) 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted January 15, 2023 Share Posted January 15, 2023 For anyone interested (and in case @cubanismo didn't receive an email notification): there is now a tentative patch for this. Let me know if this fixes your problems! 1 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted March 20, 2023 Share Posted March 20, 2023 Okay, this took a little longer than anticipated, but: rmac v2.2.15 is now out! http://rmac.is-slick.com/#rmac-2-2-15 This is mainly a bugfix release, which addresses changes introduced in v2.2.14. More specifically, the code against exporting fixups that are used as a part of an expression was too strict and produced an error on symbols that could actually be fixed up by the linker. Happy coding! 8 Quote Link to comment Share on other sites More sharing options...
dilinger Posted June 23, 2023 Share Posted June 23, 2023 To whom it may concern, in the download page at http://rmac.is-slick.com/download/download/ The 2.2.15 links point on the 2.2.14 version. WINDOWS BINARIES rmac 2.2.15 (x64) 2.2.15 (x86) 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.