Jump to content
IGNORED

RMAC/RLN


Orion_

Recommended Posts

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!

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

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!

  • Like 2
  • Thanks 4
Link to comment
Share on other sites

  • 1 month later...

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 by Ericde45
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 by ggn
  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...
  • 1 month later...
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 ;)

  • Like 2
Link to comment
Share on other sites

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!

  • Like 5
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
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.

Link to comment
Share on other sites

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).

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!)

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

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!

  • Like 8
Link to comment
Share on other sites

  • 3 months later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...