GCC 6.2 toolchain for AmigaOS 3 - Page 38

wawa · 05 February 2018, 04:09

Quote:

Originally Posted by wawa

but at the beginning of the line semicolon is clearly meant as a comment, i believe? parsing this shouldnt break anything i quess.

now i see semicolon is being used as a comment also in the middle of the line in asm code. i see, this is difficult. this whole asm stuff looks like a lot of mess, at least to a newbie..

bebbo · 05 February 2018, 10:25

Quote:

Originally Posted by Marlon_

Are you using this: https://github.com/bebbo/amigaos-cross-toolchain

Or are you using this: https://github.com/bebbo/amiga-gcc

?

manual execution of

Code:

cd submodules/binutils-2.14
git pull --depth <number>

try 4, then 8, then ... until it succeeds

or use amiga-gcc

wawa · 05 February 2018, 12:35

its no use. i cant afford to completely fetch anew being on limited connection. looks like i have to wait till stationary one arrives here.

btw, ive posted it alrerady elsewhere, but do you know how to correctly spell the likes of
bset.b #0,4(a1)
in order to have gcc4 and 6 to swallow it?

bebbo · 05 February 2018, 12:38

Quote:

Originally Posted by wawa

its no use. i cant afford to completely fetch anew being on limited connection. looks like i have to wait till stationary one arrives here.

Code:

cd submodules/binutils-2.14
git pull --depth 10

Quote:

Originally Posted by wawa

btw, ive posted it alrerady elsewhere, but do you know how to correctly spell the likes of
bset.b #0,4(a1)
in order to have gcc4 and 6 to swallow it?

my gcc6 / gas considers this as valid insn.
with gcc4 I can't help

wawa · 05 February 2018, 12:55

i ve already tried insane depths to no reward. something must be messed up:

Quote:

error: no such remote ref f494ffb0f9f668a9111d7ad3afa2d7a50a348a53
Fetched in submodule path 'submodules/binutils-2.14', but it did not contain f494ffb0f9f668a9111d7ad3afa2d7a50a348a53. Direct fetching of that commit failed.
ERROR: command "git submodule update" failed with 1

i give up for now. actually i just wanted to compare with aros m68k gas. because if it works with your compiler, it should actually work wirth ours, but it doesnt, even with expliciteld definef
#define REGISTER_PREFIX_OPTIONAL 1
so, any idea where that bit of code might be, that makes the difference?

bebbo · 05 February 2018, 18:47

Quote:

Originally Posted by wawa

i ve already tried insane depths to no reward. something must be messed up:

ups - guess I forgot to push binutils...
... try again

Quote:

Originally Posted by wawa

i give up for now. actually i just wanted to compare with aros m68k gas. because if it works with your compiler, it should actually work wirth ours, but it doesnt, even with expliciteld definef
#define REGISTER_PREFIX_OPTIONAL 1
so, any idea where that bit of code might be, that makes the difference?

sorry - no idea what it was... compare should show you the difference

wawa · 06 February 2018, 01:46

probably most significant differences are in gas/config, in particular in tc-m68k. h and .c. perhaps m68k-parse.y and .h may contain something, even though i dont really see something relevant in this case. might be that the introduction of hunk format and definitions really matters. will be really difficult to merge should i attempt it. especially remembering that aros changes are being kept conservative in order to keep the possibility open to push up some day, even if unlikely..

Marlon_ · 06 February 2018, 02:08

Quote:

Originally Posted by wawa

push up some day, even if unlikely..

What do you mean, push up?

wawa · 06 February 2018, 03:19

yes, but not a bra, i mean they reserve a chance to deliver patches to the main repo upstream. abd they want them to be overseeable in order to have a chance that theyll be accepted.

Marlon_ · 06 February 2018, 03:21

Quote:

Originally Posted by wawa

yes, but not a bra, i mean they reserve a chance to deliver patches to the main repo upstream. abd they want them to be overseeable in order to have a chance that theyll be accepted.

Ah, you mean the gcc main repo. Gotcha'

bebbo · 06 February 2018, 12:18

Quote:

Originally Posted by Toni Wilen

...
CMP.W #0,An vs MOVE.L An,Dn (just mentioning it again).

But this is now mainly nitpicking, it is now good enough

done - should be live in few minutes - and hopefully does not kill to much^^

wawa · 06 February 2018, 19:03

just dropping by again to say that i have built the toolchain now. i also tried my issue with an isolated testcase and need to correct myself. all compilers inclusive aros6.3.0 and bebbos are apparently fine with moto syntax in question (frying pan inlines)

bebbo · 08 February 2018, 00:27

update info (for amiga-gcc):

my amiga hunk m68k-amigaos-objdump version supports mixing C-source into the asm code again.

Code:

> m68k-amigaos-objdump -dS hello-ks13
...
000000fc<_main>:
int __initlibraries = 0;

struct DosLibrary *DOSBase = NULL;

int main() {
  fc:   48e7 3002       movem.l d2-d3/a6,-(sp)
  if ((DOSBase = (struct DosLibrary *) OpenLibrary((UBYTE*)"dos.library", 34))) {
 100:   2c79 0000 006c  movea.l 6c<_SysBase>,a6
 106:   43fa ffd8       lea e0<___restore_a4+0x8>(pc),a1
 10a:   7022            moveq #34,d0
 10c:   4eae fdd8       jsr -552(a6)
 110:   23c0 0000 0038  move.l d0,38<_DOSBase>
 116:   672a            beq.s 142<_main+0x46>
    Write(Output(), "Hello world!\n", 13);
 118:   2c40            movea.l d0,a6
 11a:   4eae ffc4       jsr -60(a6)
 11e:   2c79 0000 0038  movea.l 38<_DOSBase>,a6
 124:   2200            move.l d0,d1
 126:   243c 0000 00ec  move.l #236,d2
 12c:   760d            moveq #13,d3
 12e:   4eae ffd0       jsr -48(a6)
    CloseLibrary((struct Library *)DOSBase);
 132:   2c79 0000 006c  movea.l 6c<_SysBase>,a6
 138:   2279 0000 0038  movea.l 38<_DOSBase>,a1
 13e:   4eae fe62       jsr -414(a6)
  }
  return 0;
}
 142:   7000            moveq #0,d0
 144:   4cdf 400c       movem.l (sp)+,d2-d3/a6
 148:   4e75            rts
...

pipper · 08 February 2018, 00:30

Wohoo! I also used to print the assembly (via -s) but that looks rather coarse. Huge chunks of source followed by huge chunks of assembly. I’ll test the new objdump tonight.

pipper · 08 February 2018, 07:14

Is there anything special I have to do? I compiled the exe with -g, produced the disassembly via
m68k-amigaos-objdump -M -h -d -S bin/ADoom > Adoom.s

But I'm not getting finegrained assembly interleaved with source. Instead, relatively large chunks of source (whole functions) and large chunks of assembly.

bebbo · 08 February 2018, 10:25

Quote:

Originally Posted by pipper

Is there anything special I have to do? I compiled the exe with -g, produced the disassembly via
m68k-amigaos-objdump -M -h -d -S bin/ADoom > Adoom.s

But I'm not getting finegrained assembly interleaved with source. Instead, relatively large chunks of source (whole functions) and large chunks of assembly.

I'm only providing the stab information to objdump, creation is a different thing.

And I guess you're also optimizing the code... try -O0 (and you have to fix the code of ADoom, some inlines need static...)

pipper · 08 February 2018, 21:06

I tried -O0, but no avail. Is there anything else I need to provide to gcc other than -g?

Looking at the ouput of -Wa,-adhln -g ; the .stabd get nicely interleaved with the source.

Interestingly, "m68k-amigaos-objdump -G bin/ADoom " just says:

bin/ADoom: file format amiga

As if there are no stabs in there(?)

bebbo · 08 February 2018, 23:19

Quote:

Originally Posted by pipper

I tried -O0, but no avail. Is there anything else I need to provide to gcc other than -g?

Looking at the ouput of -Wa,-adhln -g ; the .stabd get nicely interleaved with the source.

Interestingly, "m68k-amigaos-objdump -G bin/ADoom " just says:

bin/ADoom: file format amiga

As if there are no stabs in there(?)

-G is working with object files. in loadable modules (exe) all .stab/.stabstr hunks are merged into one unnamed debug hunk.

Toni Wilen · 10 February 2018, 10:06

PFS3AIO still seems to compile without weird crashes.

But I noticed few unnecessary absolute addressses:

Code:

	if (!IntuitionBase ||
#ifndef KSWRAPPER
		!UtilityBase ||
#endif
		!DOSBase)
	{
		NormalErrorMsg (AFS_ERROR_LIBRARY_PROBLEM, NULL, 1);
		Wait (0);
	}

Code:

0801CCCA 244b                     MOVEA.L A3,A2
0801CCCC 7001                     MOVE.L #$01,D0
0801CCCE 93c9                     SUBA.L A1,A1
0801CCD0 41f9 0801 e1da           LEA.L $0801e1da,A0
0801CCD6 4eba 1818                JSR (PC,$1818) == $0801e4f0
0801CCDA 7000                     MOVE.L #$00,D0
0801CCDC 4eae fec2                JSR (A6, -$013e) == $080006d2

0801E1DA 436F 756C 646E 2774 206F 7065 6E20 6C69  Couldn't open li
0801E1EA 6272 6172 7921 0050 6C65 6173 6520 6672  brary!.Please fr

It seems many messages.c references are absolute even when difference is less than +-32k.

CMP.W #0,An -> MOVE change seems to work:

Code:

0801DB46 206b 0010                MOVEA.L (A3, $0010),A0
0801DB4A 2208                     MOVE.L A0,D1
0801DB4C 6776                     BEQ.B #$76 == $0801dbc4
0801DB4E 3228 0050                MOVE.W (A0, $0050),D1
0801DB52 6774                     BEQ.B #$74 == $0801dbc8

bebbo · 10 February 2018, 10:24

Quote:

Originally Posted by Toni Wilen

PFS3AIO still seems to compile without weird crashes.

But I noticed few unnecessary absolute addressses:

Code:

    if (!IntuitionBase ||
#ifndef KSWRAPPER
        !UtilityBase ||
#endif
        !DOSBase)
    {
        NormalErrorMsg (AFS_ERROR_LIBRARY_PROBLEM, NULL, 1);
        Wait (0);
    }

Code:

0801CCCA 244b                     MOVEA.L A3,A2
0801CCCC 7001                     MOVE.L #$01,D0
0801CCCE 93c9                     SUBA.L A1,A1
0801CCD0 41f9 0801 e1da           LEA.L $0801e1da,A0
0801CCD6 4eba 1818                JSR (PC,$1818) == $0801e4f0
0801CCDA 7000                     MOVE.L #$00,D0
0801CCDC 4eae fec2                JSR (A6, -$013e) == $080006d2

0801E1DA 436F 756C 646E 2774 206F 7065 6E20 6C69  Couldn't open li
0801E1EA 6272 6172 7921 0050 6C65 6173 6520 6672  brary!.Please fr

It seems many messages.c references are absolute even when difference is less than +-32k.

The referenced string is not in the same source file -> absolute address taken.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New GCC based dev toolchain for AmigaOS 3.x	cla	Coders. Releases	8	24 December 2017 10:18
Issue with photon/xxxx WinUAE Toolchain	arpz	Coders. Asm / Hardware	2	26 September 2015 22:33
New 68k gcc toolchain	arti	Coders. C/C++	17	31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5	Bobic	Amiga scene	1	23 July 2015 21:04
From gcc to vbcc.	Cowcat	Coders. General	9	06 June 2014 14:45

05 February 2018, 12:35	#743
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	its no use. i cant afford to completely fetch anew being on limited connection. looks like i have to wait till stationary one arrives here. btw, ive posted it alrerady elsewhere, but do you know how to correctly spell the likes of bset.b #0,4(a1) in order to have gcc4 and 6 to swallow it?

06 February 2018, 01:46	#747
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	probably most significant differences are in gas/config, in particular in tc-m68k. h and .c. perhaps m68k-parse.y and .h may contain something, even though i dont really see something relevant in this case. might be that the introduction of hunk format and definitions really matters. will be really difficult to merge should i attempt it. especially remembering that aros changes are being kept conservative in order to keep the possibility open to push up some day, even if unlikely..

06 February 2018, 03:19	#749
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	yes, but not a bra, i mean they reserve a chance to deliver patches to the main repo upstream. abd they want them to be overseeable in order to have a chance that theyll be accepted.

06 February 2018, 19:03	#752
wawa Registered User Join Date: Aug 2007 Location: berlin/germany Posts: 1,054	just dropping by again to say that i have built the toolchain now. i also tried my issue with an isolated testcase and need to correct myself. all compilers inclusive aros6.3.0 and bebbos are apparently fine with moto syntax in question (frying pan inlines)

08 February 2018, 00:30	#754
pipper Registered User Join Date: Jul 2017 Location: San Jose Posts: 653	Wohoo! I also used to print the assembly (via -s) but that looks rather coarse. Huge chunks of source followed by huge chunks of assembly. I’ll test the new objdump tonight.

08 February 2018, 07:14	#755
pipper Registered User Join Date: Jul 2017 Location: San Jose Posts: 653	Is there anything special I have to do? I compiled the exe with -g, produced the disassembly via m68k-amigaos-objdump -M -h -d -S bin/ADoom > Adoom.s But I'm not getting finegrained assembly interleaved with source. Instead, relatively large chunks of source (whole functions) and large chunks of assembly.

08 February 2018, 21:06	#757
pipper Registered User Join Date: Jul 2017 Location: San Jose Posts: 653	I tried -O0, but no avail. Is there anything else I need to provide to gcc other than -g? Looking at the ouput of -Wa,-adhln -g ; the .stabd get nicely interleaved with the source. Interestingly, "m68k-amigaos-objdump -G bin/ADoom " just says: bin/ADoom: file format amiga As if there are no stabs in there(?)

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)