ggn

This tweet tells you all you need to know about containers: This is of course the main reason we don't provide linux binaries for rmac and rln: we'd have to assume that the user links against the same version of libc we do - not a great idea. Containers for development is a weird concept: on linux you're pretty much a stone's throw away from installing dev tools and building things from source if something is missing from your setup. On Windows it's a non-issue: binary compatibility goes back decades, so there's a high chance your binary will work (worst case you have to add spefic VC runtime dlls, but those too are standarised). Unsure about macs, but the binaries for rmac/rln we create seem to work fine for people so far. While trying to add the compilers from http://brownbot.mooo.com upstream to http://godbolt.org I had to use containers to test things. It was a horrible experience: tons of MBs of things had to be downloaded and installed somewhere in the disk, and then each test I made the contained had to be spun, run, and had a really bad way to communicate errors when things went wrong. (oh yeah, containers not shutting down and remaining running without any feedback to they user were very fun things too). And of course I remember something along the lines of each time I changed something to the config of the container, it would start downloading the universe again because OMG we can't be sure what we've downloaded already, it might be different! So....... why do people even want this? Why do someone have to spin a mini VM (which is what I understand containers are) in order to just convert a couple of text files into machine language? It doesn't make much sense to me On most (all?) of my projects I have 0 things installed. The tools are all contained in the project (usually rmac and gfa32 which also is portable and needs no install). Worst case if I need a C compiler or whatever, I do have a ZIP file with that packed somewhere, ready to be deployed. But even that is not installed, ever. This really makes me curious to ask what people's workflows are. All I'm saying is: keep it simple, people, it's not rocket science!

Ship it!

Oh, floats. Well, in the past I've used https://github.com/ggnkua/pml-bigbrownbuild which is still not built using the build script. I think this repo is kind of patched up to work with newer gas format. If memory serves correct, just get this repo, cd to 'pmlsrc', edit 'Makefile.16' and 'Makefile.32' to the right paths. Then type 'make -f Makefile.16', copy the .a file somewhere, then 'make -f Makefile.32'. I cannot remember which of the two I used in the past but at least one should work.

All right, so unless someone proves otherwise, rmac isn't getting a parameter in the STOP opcode.

Dunno, probably. I just work here, man! (by that I mean: I didn't write the OP portions, @Shamus did actually. And I haven't looked that serious at how the bits are laid out, sorry!) (but it'll be correct by the time we issue the fix!)

Hello, A quick glance at the codebase (http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=rmac;a=blob;f=op.c;h=836f4de173b01add2b452414574c98b9c5c13953;hb=HEAD#l428)shows that the implementation of stop does not not take a parameter. We can add it easily though, no probs. As a workaround for now you can use something like the following in lieu of the stop opcode: dc.l 4<<28,O_STOPINTS (not tested, but it's probably fine)

I also sent a payment in August 21 but still have no reply or confirmation. Is everything ok?

At least versions 4 onward do that, yes. If you want a particular file to not touch more registers you can compile the file with, for example, -fcall-used-d2.

Same here, one please

Hi folks, Due to reasons I'd rather not discuss, I'm henceforth stopping all RB+ development and support. The github and bitbucket repositories will remain in place for a couple of days and will then be taken down. Thank you for all your interest in this experiment, it's been a fun 6 years. It's time to move on. Please don't PM me or ask me about this using any means, messages will be ignored. See you around, GGN

Okay, you got me too. So let's back that bus up. First of all, are you able to build zyx in any way right now? Secondly, did you always had assets marked as ROM or did you do that now that you're getting build errors?

Ok, issue found. Head over to token.h, lines 131 and 132 and change the "32" to "64". Also read the comment, you just broke a record ;). I'll have a discussion with Shamus on how to handle with this but you should be fine for now...

http://jlhconsulting.gotdns.com/bugs/buglist.cgi?component=Core&product=RMAC&resolution=---&list_id=388 but this thread is ok too.

Also, I just submitted a patch for the macro issues that @SebRmv has. Hopefully it will be merged with the main tree, in the meantime the adventurous can try it out for themselves :).

Awww shucks guys, you're the best! I opened the page and saw half a page's worth of new messages and thought I'd have to spend a few hours testing things, but everything was resolved at the end :). A couple of notes: I thought I fixed the issues with error reporting while evaluating macros and REPTs, but it seems it's not perfect yet. I'll have another go at it. In the meantime an accurate way to pinpoint the expanding issues is to produce a listing (switch -l or -l* if you prefer no pagination). As for the rest of the patches, hopefully @Shamus will get around to integrating them into the repository so people don't have to do magic hocus pocus all the time, but grab a binary instead and do some work @SebRmv thanks for trying out rmac and don't hesitate to report any issues!

I assume you're trying to compile it by hand instead of using the supplied makefile? That won't work as some tools need to be built and produce some header files before the main code can be compiled. In other words, did you try typing "make"?

"Unavailable"?

Can you please paste your build log?

Of course you can always use rmac since the test suite I posted above passes (after all it was designed to test the assembler :). For now only XEX format is supported, more will be added if people ask!

Hi there, I've added a fix for the issue you raised on the issue tracker. If you could compile and test rln, it'd be great.

Aaaaand we're probably fine now. Just waiting for Shamus to confirm and commit the fix and a new version will be released. For the impatient, grab the patch and build the assembler yourself :).

Just to give an update: This is in the process of being fixed. Actually, there is a fix right now but it breaks other cases. (2020 is going to be the year of bad symbol exports by the looks of it)

Do you still have that? It doesn't ring a bell here!

In the latest released versions you still had to insert comment lines to simulate blank lines. At least the editor auto formatted the code for you so you needn't have to worry about it. (However I was under the impression that v2.0 also auto formatted code)

Well, you got me there. I thought about checking the code for RMACPATH but thought "It's probably fine, besides: who even uses RMACPATH"? Well, now we know! Thanks!