GCC 3.2.3 and binutils 2.14a

[kerravon]

Hi.

Because of work done on the mainframe, I have spent a lot of effort making GCC 3.2.3 a C90-compliant application, e.g. it doesn't call fork().

Because of work done on PDOS/386, I have also made binutils 2.14a C90-compliant.

But in both cases, this C90-compliant source code that should work out of the box with any C compiler only supports the targets I have hand-crafted and created a makefile for. I have my own "make" program too - pdmake, which doesn't require tabs.

I would now like to get both of these custom distributions to support targeting 68000 Amiga hunks.

Ideally I'd like it to use the Motorola syntax for assembly.

From searching on the web, it seems that the Amiga hunk format was never officially supported for binutils but there was unofficial support for it and/or a tool to convert from ELF to Amigahunk. Ideally if someone has spent the effort to properly support Amigahunk, I would like that incorporated into my product, to help preserve the technology.

I'll need something that doesn't violate the GPL license that these products are copyrighted under.

Could someone please provide direction within the above constraints?

Thanks.

[Samurai_Crow]

https://github.com/bebbo/binutils-gdb is the binutils for Bebbo's GCC 6.5 cross compiler.

[kerravon]

Originally Posted by Samurai_Crow

https://github.com/bebbo/binutils-gdb is the binutils for Bebbo's GCC 6.5 cross compiler.

Thanks. Within that I found bfd/amigaos.c which is 4000 lines of code and mentions "hunk" a lot, and has the sort of dates I am looking for:

/* BFD back-end for Commodore-Amiga AmigaOS binaries.
Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998
Free Software Foundation, Inc.
Contributed by Leonard Norrgard. Partially based on the bout
and ieee BFD backends and Markus Wild's tool hunk2gcc.
Revised and updated by Stephan Thesing.


So hopefully that doesn't have post-2.14a features and still works in 2.14a and I can figure out how to incorporate it.

[Samurai_Crow]

You're welcome!

[kerravon]

I guess there's a fundamental problem here that the owners of GCC/binutils mainstream don't say "oh wow, you support the Amiga - that's fantastic!" and work to incorporate that into the mainstream. Similarly, they actually said out loud that they were "keen to delete" the i370 mainframe target which I was working on.

One thing I noticed with my C library, which supported MVS, was that suddenly I had someone contact me with code changes for CMS.

I think I will make my distributions a repository for "retro" computing.

[kerravon]

Actually it's more than just retro. The problem is that the build system relies on you being able to run some shell, which may not exist. For people who just have a C compiler, such as SAS/C, I am expecting a simple makefile that builds a simple set of C files. Which is in fact what I have been creating in my distributions. So the Amiga will just be part of that.

[kerravon]

Originally Posted by kerravon

/* BFD back-end for Commodore-Amiga AmigaOS binaries.
Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998

Unfortunately it looks like this code has been changed since 1998 and the copyright headers just haven't been updated.

I tried changing the code I had, but ran into a problem with amigaoslink.c where I'm unsure what changes to make. It's certainly non-trivial.

binutils 2.14 is dated 2003 and binutils 2.14a is dated 2011, so there should have been an 8-year period when every GCC distribution used this. Anyone have a link to the Amiga code for this time period? It'd be terrible if this stuff was lost. I actually chose 2.14a because it was before they deleted a target I was interested in (i386-aout) and should have been compatible with GCC 3.2.3 which was released in 2003, and had years of stability. I'm not after the latest greatest features, I'm after stability because I'm trying to make a viable product instead of replacing one set of bugs that are not affecting me with a set of bugs that may affect me. I've already fixed two bugs in 2.14a that affected Windows PE and i386-aout.

Here are the old binutils:
https://ftp.gnu.org/gnu/binutils/

[patrik]

Might the source for binutils from the Fred Fish ADE/GG help? It is an older version of the bfd/amigaos.c and I think ADE/GG is where the amiga-gcc stuff came from, but please correct me if I am wrong.

http://aminet.net/package/dev/gg/binutils-src

[phx]

Originally Posted by kerravon

Ideally I'd like it to use the Motorola syntax for assembly.

Full compatibility doesn't work. AFAIK, later gcc versions can emit most instructions and adressing modes following the Motorola syntax (except for differences like "mov", "movm" or "jra"), but the assembler directives will stay the same.

From searching on the web, it seems that the Amiga hunk format was never officially supported for binutils but there was unofficial support

I have been in contact with Gunther Nikl (gnikl) over the last years, and he still worked on improving hunk support in binutils. You may want to contact him to get the latest source. I'm also quite sure he worked with GCC3 sources at that time.

I'll need something that doesn't violate the GPL license that these products are copyrighted under.

Without that restriction you might even be able to assemble your gcc-output with vasm (using -gas and -elfregs options). I got some support for it, because Gunther also experimented with replacing binutils by vasm/vlink.

[kerravon]

Originally Posted by patrik

Might the source for binutils from the Fred Fish ADE/GG help? It is an older version of the bfd/amigaos.c and I think ADE/GG is where the amiga-gcc stuff came from, but please correct me if I am wrong.

http://aminet.net/package/dev/gg/binutils-src

Thanks. I downloaded that, and it is indeed an older version of the Amiga code. Unfortunately it is too old and that binutils is not compatible with 2.14a either, and also not trivial to fix. It's probably best for me to triangulate using the newer version of binutils as a base. But ideally someone has already done this as there was a very long period of binutils 2.14 stability from my reading of the release dates.

[kerravon]

Originally Posted by phx

Full compatibility doesn't work. AFAIK, later gcc versions can emit most instructions and adressing modes following the Motorola syntax (except for differences like "mov", "movm" or "jra"), but the assembler directives will stay the same.

Ok, well since I use separate assembly anyway, the main thing I am after is for gas/as to support this assembler code:

https://sourceforge.net/p/pdos/gitco...b/amistart.asm

I have been in contact with Gunther Nikl (gnikl) over the last years, and he still worked on improving hunk support in binutils. You may want to contact him to get the latest source. I'm also quite sure he worked with GCC3 sources at that time.

I tried sending a PM to that userid but it was unknown.

Without that restriction you might even be able to assemble your gcc-output with vasm (using -gas and -elfregs options). I got some support for it, because Gunther also experimented with replacing binutils by vasm/vlink.

I already have vbcc/vasm/vlink working. I'd now like to have gcc/as/ld working.

[kerravon]

Originally Posted by kerravon

But ideally someone has already done this as there was a very long period of binutils 2.14 stability from my reading of the release dates.

I found what looks like exactly what I need:

https://github.com/bebbo/amigaos-binutils-2.14

I've verified the code seems to be inbetween the other 2 releases, and now I'm trying to beat it into shape.

[kerravon]

Originally Posted by kerravon

I found what looks like exactly what I need:

https://github.com/bebbo/amigaos-binutils-2.14

I've verified the code seems to be inbetween the other 2 releases, and now I'm trying to beat it into shape.

Great news! I managed to get it to build.

My assembler code has these errors though:

F:\devel\pdos\pdpclib>\devel\binutils-2.14a\as-pdos amistart.asm
amistart.asm: Assembler messages:
amistart.asm:24: Error: Unknown operator -- statement `section "CODE",code' ignored
amistart.asm:25: Error: Unknown operator -- statement `xref ___start' ignored
amistart.asm:51: Error: Unknown operator -- statement `section "BSS",bss' ignored

I commented those lines out and it compiled without error and produced this, which looks like Amiga format:

F:\devel\pdos\pdpclib>hexdump a.out
000000 000003E7 00000002 612E6F75 74000000 ........a.out...
000010 000003E8 00000002 2E746578 74000000 .........text...
000020 000003E9 0000000A 23CF0000 00222F07 ........#...."/.
000030 2F082F00 4EB90000 00004FEF 000C4E75 /./.N.....O...Nu
000040 202F0004 2E7A0004 4E750000 00000000 /...z..Nu......
000050 000003EC 00000001 00000000 00000002 ................
000060 00000000 000003EF 81000002 5F5F5F73 ............___s
000070 74617274 00000001 0000000E 01000003 tart............
000080 5F5F5F61 6D697374 61727400 00000000 ___amistart.....
000090 01000002 5F5F5F65 78697461 00000018 ....___exita....
0000A0 00000000 000003F2 ........


Where do I stand now? I'd like to support both vasm and gas/as. Should I be using conditional compilation to support both formats? Or should I change my code to be gnu format (not sure what it requires yet) and then use a parameter to vasm to accept that format?

Another thing is that I will need to use "ar" and I don't think "ar" supports Amiga format. I need to use a.out instead I think for object code, to produce a .a and then "ld" can produce an Amiga hunk.

I'm going to work on gcc 3.2.3 now.

[kerravon]

Originally Posted by kerravon

I'm going to work on gcc 3.2.3 now.

More good news! I was able to get gcc 3.2.3 to target 68020 (I think). What this means is that we now have a C90-compliant compiler, meaning it can run in hostile (non-POSIX) environments like PDOS-generic (under Amiga OS).

I'm not sure whether the calling convention is correct though. It's generating this code:

int foo(int a, int b)
{
return (a+b);
}

#NO_APP
.text
.even
.globl _foo
_foo:
link a6,#0
movel a6@(8),d0
addl a6@(12),d0
unlk a6
rts


and it needs to be compatible with this code:

___amistart:
move.l sp,savedSP

* Don't use movem to push the arguments because the order
* is not what you code yourself, but other rules.
move.l d7,-(sp)
move.l a0,-(sp)
move.l d0,-(sp)

jsr ___start
lea 12(sp),sp
rts

although I guess I can always just change the startup code.

But it also needs to work with this code:

Read:
MOVEM.L D2/D3/A6,-(A7)
MOVEA.L _DOSBase,A6
MOVEM.L 16(A7),D1/D2/D3
JSR -042(A6)
MOVEM.L (A7)+,D2/D3/A6
RTS

So that will potentially need to change too. Or I can potentially modify GCC 3.2.3 if someone can spot something wrong with the GCC-generated code.

Note that the GCC-generated code is able to be assembled with the binutils "as" I previously created.

I'm now going to get "ar" and "ld" to build. Note that my binutils is also C90-compliant.

[kerravon]

"ld" is taking a long time to crack.

Even though I have the binutils 2.14 source, as usual, the GNU people don't provide C90 code that compiles on any compiler. You instead need to be able to support bash or similar. It so happens I have Cygwin installed, but it still breaks. The older version breaks too. So working source code remains elusive.

However, with a separate configure in the "ld" directory I was able to get "ld" built.

Using this configure command:

./configure --target=m68k-unknown-aout --with-sysroot --disable-nls --disable-werror

on the Amiga 2.14 source code I downloaded, I get this, which looks wrong:

ld-new: supported targets: a.out-zero-big cisco-ios-core-big ieee srec symbolsrec tekhex binary ihex
ld-new: supported emulations: m68kaout


It looks like it is building 64-bit a.out instead of 32-bit Amiga hunks.

Does anyone know the principles at play here? What are we expecting to see from "ld"? When I do my own build I get this:

ld-pdos: can't set BFD default target to `m68k-unknown-aout': Invalid bfd target

[phx]

Originally Posted by kerravon

F:\devel\pdos\pdpclib>\devel\binutils-2.14a\as-pdos amistart.asm
amistart.asm: Assembler messages:
amistart.asm:24: Error: Unknown operator -- statement `section "CODE",code' ignored

As I already mentioned, GNU-as doesn't understand Motorola-syntax directives.

I commented those lines out and it compiled without error and produced this, which looks like Amiga format:

Without the

section

directives everything is written into the

.text

section. Not necessarily what you want.

Or should I change my code to be gnu format (not sure what it requires yet) and then use a parameter to vasm to accept that format?

This.
Unlike GNU-as, vasm supports multiple syntax styles. So you could write your assembler sources in GNU-as syntax and compile vasm with

make CPU=m68k SYNTAX=std

.

Another thing is that I will need to use "ar" and I don't think "ar" supports Amiga format.

Theoretically you can put anything into an ar-archive you like. But most linkers won't expect hunk-format object files in such a linker library.

I need to use a.out instead I think for object code, to produce a .a and then "ld" can produce an Amiga hunk.

Might work, in many cases. Although a.out doesn't support all features of hunk-format.

Originally Posted by kerravon

movel a6@(8),d0
addl a6@(12),d0
unlk a6
rts

That's the infamous MIT syntax for m68k. Probably no other m68k assembler, other than GNU-as, supports it.

[kerravon]

Good news. I have managed to build ld and ar. "ld" was a can of worms. The fundamental problem was that I didn't know you needed to configure with m68k-amigaos and because of the mention of a.out I thought that the a.out target had been modified to build the Amiga, so I had configured with m68k-aout and when I tried to reconfigure with different options, I didn't realize that they weren't taking effect in the subdirectories. A clean configure does in fact build usable code. I have now merged both bebbo's 2.14 mods and mine. Another problem was that the Amiga target was using the non-C90 function "fstat" which I only had a stub for, and when I realized that that might be the cause of the mostly-empty executables, I reworked the binutils code to stop using fstat.

The end result is at http://pdos.org/custom.zip
(that's both binutils 2.14a and gcc 3.2.3)

So this is useful if you only have a C90 environment. I'll distribute Windows executables as part of the PDOS/386 distribution in due course.

Originally Posted by phx

As I already mentioned, GNU-as doesn't understand Motorola-syntax directives.

Thanks, I now understand what that means and I have switched to std syntax which works for both assemblers. Awaiting test results. One gotcha I found was that with std syntax, a leading 0 seems to be octal, and it took a while before I realized that that's why it was rejecting my offsets (generated by fd2pragma).

Theoretically you can put anything into an ar-archive you like. But most linkers won't expect hunk-format object files in such a linker library.

I have confirmed that "ar" accepts storing hunks in there and "ld" accepts an archive containing hunks.

That's the infamous MIT syntax for m68k. Probably no other m68k assembler, other than GNU-as, supports it.

Ok, I don't care if it puts out MIT syntax so long as I don't need to look at it and the stack calling convention is correct. I'll see if I have been successful with that in due course. I don't think there's a way to change that in GCC, and in the assembler I went looking for the m68k equivalent of i386 ".intel_syntax noprefix" but it looks like there is no such thing and the Motorola syntax is just quietly accepted alongside MIT.

Anyway, that means my GCC 3.2.3 based system can now build Windows, MVS and Amiga executables so that I can do a better job of triangulating and abstracting.