GNUMake option?

[debmint]

I wonder why in the GNUMake-files, you use the option "-mx32" instead of "-m32". I have two Linux distros - Manjaro and Debian (10). and neither will compile without installing a bunch of packages. Both are set up to build with the -m32 opt. AIUI, -mx32 builds a 64-bit program with longs,etc set to that of 32-bit systems, while -m32 simply builds a 32-bit program. I have a Mint system that has the proper modules, possibly all were packaged together.

I was looking over your CC09 sources and noticed that this is the "old" version - the same as we have available on the CoCo. The version on toolshed (in the c3 directory) is the "new" version where the first parameter to a function is passed in the "D" register. If it's not secret, I was just wondering where you came up with this version. BTW, the programs in the Level 2 Development pak - rma, etc, are built wih the "new" version.

[Deek]

It started out as the "new" version, which was incompatible with all libraries and compiled code for the old compiler. I figured out what made it incompatible, and hid that code behind #ifdef REGPARMS sections.

[Deek]

You can change the compiler options to use -m32 if you like, it still works. I am using -mx32 because it's more likely to break if I do something wrong.

[debmint]

On Mon, Jun 6, 2022 at 4:33 AM Jeff Teunissen ***@***.***> wrote: It started out as the "new" version, which was incompatible with all libraries and compiled code for the old compiler.

Actually, the libraries are included in the c3 package in toolshed-code.

I figured out what made it incompatible, and hid that code behind #ifdef REGPARMS sections.

That explains a lot! :) I did a checkout of the toolshed commit where they first added it and diffed it with your code and could find nothing that appeared to affect this. Why I'm interested in the "new" code is that all the l2 dev programs use this interface and when I compare a disassembly of the original with what my attempts build, it removes a _bunch_ of differences. There must have been a lot of differences because if I remember correctly, there are quite a bunch of these conditionals. I was primarily looking for somewhere where a call to "pshs ..." got changed to "tfr ?,d", although I suspected that there would be more to it. I suppose you also saw my other post in issues where I told you I have my disassembled version of "rlink" working. The code built from my build seems to match, and in fact, if I use my build of co_opt (under linux), it produces an exact match. I'm also using my build of "rma" under linux so that would imply that this, also is working for the most part. However, there may be some special case where it might fail. One case in point, I built the "optexp" version to run in linux - actually I built all the *exp" packages. Anyway, for some reason, it crashes when making rl_02.r, but if I use your dco68, it misses _one_ return where your precompiled dc068 running in coco does a "lbra" to a similar return. Again, last time I tried, using my "co_opt" with original c.opt in coco produced identical module. Thanks for replying. It solved some curiosities I had. I'm assuming you might be more interested in doing things on native coco or emulator, but if you would be interested in incorporating my rlink into your project, I'd be happy to help get it done. I played around a bit with merging a git project into another with its history and was able to do this on some of my local repos.

[Deek]

Actually, the libraries are included in the c3 package in toolshed-code.

Yes, but they can't be used by the old compiler and the new compiler can't use libs for the new one. For that reason, it's pretty much a non-starter unless we can get real source for every lib available. I kept the code working, you just need to enable it to do test compiles etc. on Linux.

I'm assuming you might be more interested in doing things on native coco or emulator, but if you would be interested in incorporating my rlink into your project, I'd be happy to help get it done. I played around a bit with merging a git project into another with its history and was able to do this on some of my local repos.

I'm reasonably experienced with importing parts of repositories with history into projects, where is the repo located?

[debmint]

On Tue, Jun 7, 2022 at 7:16 PM Jeff Teunissen ***@***.***> wrote:

On Mon, Jun 6, 2022 at 4:33 AM Jeff Teunissen *@*.***> wrote: It started out as the "new" version, which was incompatible with all libraries and compiled code for the old compiler. Actually, the libraries are included in the c3 package in toolshed-code. Yes, but they can't be used by the old compiler and the new compiler can't use libs for the new one. For that reason, it's pretty much a non-starter unless we can get real source for every lib available. I kept the code working, you just need to enable it to do test compiles etc. o

It would be a pretty big jump to switch, but what I did was put the "new" libs in a "c3" subdirectory and built c3 to look in that directory. I just let it use the original "defs" for its includes, as I don't think there would be any difference there.

…

but if you would be interested in incorporating my rlink into your project, I'd be happy to help get it done. I'm reasonably experienced with importing parts of repositories with history into projects, where is the repo located? I don't have it up anywhere as of now. I prefer GitLab, but if it would be more convenient for yoy, I can put it up on GitHub. If you are interested in my laatest rendition of "rma" I can put that up, too. I originally named it "r63" but Boisy changed that back to "rma". I think he made label lengths lo ger. I don't recall if I kept that or not. I'm wondering now how hard it would be to conditionally build rma with 6309 compatibility. It would be a matter of inserting a lot of "#ifdef"sMessage ID: ***@***.***>

[debmint]

I have a fork of this project (look under your forks for "debmint". I've pushed my rlink code into a branch called "addRlink", and put it in the Source directory beside Make. You can look it over and see if you approve. Can you merge this without my submitting a merge request? I have included some little utility scripts to quickly create asm source files from the original rlink and the code built by the source. I think I have the main script commented well enough to explain how to use it. In working with rlink, I found an error in the original code. It's found in rlink_main.c and I added a comment with the text BUGFIX in it if you want to check it out. If you use the script to create the compares (you have to have my coco-disasm project installed) and do a side-by-side diff, you can find it in the original code (you can search for NameFile until you get to it). This section of code is only used if you use the "-z" option and the filename is not found. If you wish to use this, feel free to do with it as you wish. On Tue, Jun 7, 2022 at 7:16 PM Jeff Teunissen ***@***.***> wrote:

…

On Mon, Jun 6, 2022 at 4:33 AM Jeff Teunissen *@*.***> wrote: It started out as the "new" version, which was incompatible with all libraries and compiled code for the old compiler. Actually, the libraries are included in the c3 package in toolshed-code. Yes, but they can't be used by the old compiler and the new compiler can't use libs for the new one. For that reason, it's pretty much a non-starter unless we can get real source for every lib available. I kept the code working, you just need to enable it to do test compiles etc. on Linux. I'm assuming you might be more interested in doing things on native coco or emulator, but if you would be interested in incorporating my rlink into your project, I'd be happy to help get it done. I played around a bit with merging a git project into another with its history and was able to do this on some of my local repos. I'm reasonably experienced with importing parts of repositories with history into projects, where is the repo located? — Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF7WTTMP5WMDZDZRDCSETDTVN7Q7TANCNFSM5RVMUJIA> . You are receiving this because you authored the thread.Message ID: ***@***.***>