GNUMake option? #16
Comments
|
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. |
|
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. |
|
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.
|
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 reasonably experienced with importing parts of repositories with history into projects, where is the repo located? |
|
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: ***@***.***>
|
|
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:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: