MorphZone

ADTools: Are there any MOS coder to join it?

munk

# 26
Butterfly

Posts: 94 from 2006/3/27

Quote:

itix wrote:
Quote:

Are you talking about __libcall__? The funny thing is that this extension causes no problems with new GCC versions. Th old GCC2 modifications apply to ALL later versions. Go figure..

Does it support 68k vararg hack too?

Of course, since __libcall__ does force __linearvarargs. I was only talking about core __libcall__ support. The core patch to the compiler for that hasn't changed since GCC2. The backend has changed and there the patches were adapted.

Quote:

According to amiga_compiler.h GCC uses

#define APICALL __attribute__((libcall))

when VBCC uses

#define APICALL __aos4libcall __linearvarargs

So that every vararg library call in OS4 uses 68k varargs instead of native SysV varargs (newlib.library being an exception).

Thats correct, but then I don't know if thats a major issue. Note: I am not associated with AOS4 in anyway. But I looked at their GCC patches. I never understood why neither MOS nor AOS4 did use the present toc-saving bits. That would have saved a lot of code addition.

Quote:

One would also ask who had this idea using (the system private) r2 as a base pointer for baserel libraries... maybe r13 was too obvious...

Please define "system" ;-) Again I don't know the reason for this decision. Not that I really care.

Quote:

Luckily you can always extend struct Process when you need new base pointer (though it makes it tricky when your code is called from other context but not impossible).

You lost me ;-) But then I don't understand where "__restore_r13" comes from - in libnix its a no-op..

Quote:

Lack of __vararg68k is not problem. You can always work around this by piece of code.

You mean a varargs macro?

Quote:

However without baserel support SDL libraries cant be compiled on anything else than GCC2. But GCC4 is not secret overclocking utility so...

Well, I didn't look into this issue (yet). I now that __varargs68k is "easy". __saveds is harder since it requires a call and with GCC3+ epilogue/prologue is now RTL code.
»07.04.06 - 12:23

itix

# 27
MorphOS Developer

Posts: 1516 from 2003/2/24

From: Finland

Quote:

Quote:

Lack of __vararg68k is not problem. You can always work around this by piece of code.

You mean a varargs macro?

Varargs macro or a small assembler stub generated by cvinclude.pl.
1 + 1 = 3 with very large values of 1
»07.04.06 - 12:55

munk

# 28
Butterfly

Posts: 94 from 2006/3/27

Quote:

Varargs macro or a small assembler stub generated by cvinclude.pl.

I see. Yes, using a stub is fine. I don't really like the varargs macro approach - to much stackspace waste.

BTW, does __varargs68k work for wrappers around functions only taking a "struct TagItem *" as paramter?
»07.04.06 - 13:09

CISC

# 29
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

But then I don't understand where "__restore_r13" comes from - in libnix its a no-op..

It comes from GCC (emitted when it needs to restore r13 out of "nowhere" (usually when a function is declared __saveds)), and it certainly is not a no-op in libnix (libnix doesn't actually have this function, as it can never be generic), you must have misunderstood something (I can guess what; you might solve the mystery by looking more closely at the asm construct and the comment)...

- CISC
»07.04.06 - 19:45

itix

# 30
MorphOS Developer

Posts: 1516 from 2003/2/24

From: Finland

@munk

Quote:

BTW, does __varargs68k work for wrappers around functions only taking a "struct TagItem *" as paramter?

I dont know. Maybe with little tweaking it is possible. Never tried.

Btw I wouldnt worry about varargs macros stack space wasting... when the PPC programs have 32kB stack as minimum it is unlikely to run out of stack because of this. On there 68k there isnt much space to waste of course.

[ Edited by itix on 2006/4/7 22:24 ]

[ Edited by itix on 2006/4/7 22:44 ]
1 + 1 = 3 with very large values of 1
»07.04.06 - 21:20

munk

# 31
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
Quote:

But then I don't understand where "__restore_r13" comes from - in libnix its a no-op..

It comes from GCC (emitted when it needs to restore r13 out of "nowhere" (usually when a function is declared __saveds))

I know that GCC emits it, I did look at the source. Thats why I asked ;-)

Quote:

it certainly is not a no-op in libnix (libnix doesn't actually have this function, as it can never be generic), you must have misunderstood something (I can guess what; you might solve the mystery by looking more closely at the asm construct and the comment)...

You are right, I missed the fact that its a local function in the libnix startup and that two functions use __saveds. Now I do understand why its there. Thanks for letting me think myself ;-)

However, I don't understand why the call to __restore_r13 is emitted for SDATA_DATA. You would need to setup r13 for SDATA_SYSV (and SDATA_EABI but that mode conflicts with the MOS usage of r2). What do I miss this time? :-)
»08.04.06 - 10:52

CISC

# 32
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

We only use SDATA_SYSV and our own SDATA_BREL, which can use the same r13, so no problem there... ;)

To see how this works in real life I suggest you get the SDK at MDC and check out the relskeleton (perhaps a better example is one of itix's libs, as they have a cleaner (less asm) way of dealing with r13 not being trashed in libinit/open) example.

- CISC
»08.04.06 - 18:22

munk

# 33
Butterfly

Posts: 94 from 2006/3/27

Quote:

Raf_MegaByte wrote:
Quote:

An effort to unify the development of patches to binutils, gdb, and GCC to support all kind of AmigaOS target platforms. One main target is to achieve an integration of the AmigaOS relevant changes to the official development projects of binutils&friends

Its _very_ unlikely that there will be support for AmigaOS support in an official binutils, gcc, etc. Thats because the changes are partly very intrusive and it it would require a lot of effort to get these in.

Quote:

So, is there any volunteer?

Maybe you missed it but adtools has no support for 68k either (only binutils and its still unknown if that support does work correctly in all cases). In general I believe its hard to do non-OS4 changes in there because it might conflict with changes done for OS4.
»10.04.06 - 12:13

munk

# 34
Butterfly

Posts: 94 from 2006/3/27

Quote:

itix wrote:
Btw I wouldnt worry about varargs macros stack space wasting... when the PPC programs have 32kB stack as minimum it is unlikely to run out of stack because of this. On there 68k there isnt much space to waste of course.]

I forgot to add that varargs macros on 68k yield in very inefficient code. On 68k GCC migh create *two* arrays for one varargs macro, one where it builds the taglist and a second one that is used as argument to the OS call (the copying takes places behind the scenes). I guess its different on PPC where you can't build argument lists on stack on the fly as done on 68k (I hope that sentence makes sense to you :-)
»10.04.06 - 12:22

munk

# 35
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
We only use SDATA_SYSV and our own SDATA_BREL, which can use the same r13, so no problem there... ;)

I know that r13 is used in both cases. However, that wasn't my point. I was aking why __saveds saves r13 for SDATA_DATA, but doesn't save it for SDATA_SYSV (aka. -mbaserel). All MOS-GCC patches I checked (including the one from zapek) test for SDATA_DATA in morphos.c/morphos_restore_r13. I think it should test for SDATA_SYSV there.

Quote:

To see how this works in real life I suggest you get the SDK at MDC and check out the relskeleton (perhaps a better example is one of itix's libs, as they have a cleaner (less asm) way of dealing with r13 not being trashed in libinit/open) example.

His library_example archive doesn't have any example about using/saving r13.
»10.04.06 - 12:35

CISC

# 36
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

I think it should test for SDATA_SYSV there.

Heh, indeed, that looks like a bug. :P

Quote:

His library_example archive doesn't have any example about using/saving r13.

I meant one of his actual libraries, not the example code.

- CISC
»10.04.06 - 22:03

munk

# 37
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
Quote:

I think it should test for SDATA_SYSV there.

Heh, indeed, that looks like a bug. :P

Glad you agree.

Is -mbaserel a supported mode? The SDK I have doesn't have such libraries and the linker complains about "symbol in wrong section".
And what about libabox.a? Does it still contain "broken" objects ? Those objects (created with Barfly) have e_version set to EV_NONE but it should be EV_CURRENT. vlink doesn't like that.

Quote:

I meant one of his (itix) actual libraries, not the example code.

Found it. PowerSDL uses baserel32 mode. Something like there I expected for __restore_r13. FWIW, its possible to use less assembly.
»11.04.06 - 12:23

CISC

# 38
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

Glad you agree.

Fixed in CVS at any rate, thanks for finding it.

Quote:

Is -mbaserel a supported mode?

Sure, but obviously broken with __saveds. :P

Quote:

The SDK I have doesn't have such libraries and the linker complains about "symbol in wrong section".

Yeah, that'd happen when you link against libraries which are not built with -mbaserel, so obviously if you use any libc funcs or stubs etc it'll either barf or link broken code (I suppose it might work if you linked with -mbaserel32, though slightly purpose-defeating) .. the SDK doesn't contain any -mbaserel built libs simply because it's not worth the effort, -mbaserel32 works just as well (-mbaserel only has the slight advantage of creating fractionally smaller code if you happen to have very little global data)...

Quote:

And what about libabox.a? Does it still contain "broken" objects ? Those objects (created with Barfly) have e_version set to EV_NONE but it should be EV_CURRENT. vlink doesn't like that.

I guess it still does, basm hasn't been changed in ages, and afaik no-one reported this "issue". ;)

Quote:

FWIW, its possible to use less assembly.

For __dbsize() then I guess...

- CISC
»12.04.06 - 18:37

munk

# 39
Butterfly

Posts: 94 from 2006/3/27
Quote:

CISC wrote:
Fixed in CVS at any rate, thanks for finding it.

No problem. Do you know if there are additional changes for binutils and gcc in CVS compared with the zapek releases?

Quote:

Quote:

Is -mbaserel a supported mode?

Sure, but obviously broken with __saveds. :P

Maybe nobody really tried to use it. There is another change in rs6000_encode_section_info that looks suspicious because it changes data access for SDATA_SYSV. The data is placed in .sdata but it gets accessed absolute (ha/l relocs). I don't think that was intended and its not necessary at all.

Quote:

Quote:

linker complains about "symbol in wrong section".

Yeah, that'd happen when you link against libraries which are not built with -mbaserel, so obviously if you use any libc funcs or stubs etc it'll either barf or link broken code

I believe linking against non-baserel code works as long as that code doesn't put data in the "wrong" section. Data access from non-baserel code is fine because its absolute. The linker errors I see are for common symbols in the source just compiled:

"The target (SysBase) of a R_PPC_SDAREL16 relocation is in the wrong section (COMMON)"

When using -mbaserel32 the symbols are still emitted as commons but this time the linker doesn't complain. Thus there must be a difference but I don't know where to look. FWIW, vlink works.

Quote:

the SDK doesn't contain any -mbaserel built libs simply because it's not worth the effort, -mbaserel32 works just as well (-mbaserel only has the slight advantage of creating fractionally smaller code if you happen to have very little global data)...

I believe thats a fair statement. Still, it would be nice to have at least libabox.a as baserel version (to avoid nasty relocs ;-) The stubs are probably not required since this is handled with the inlines just fine. I sucessfully used SDATA_SYSV with my powerup gcc, thus I tried to use it with MorphOS too since I was startled about a programs size "explosion" compared with its 68k version. And thats mostly because of relocs.

That leads to another question: Do you happen to know if the MorphOS ELF loader puts section .sbss directly after .sdata in memory? What about PowerUp?

Quote:

Quote:

"broken" objects in libabox.a?

I guess it still does, basm hasn't been changed in ages, and afaik no-one reported this "issue". ;)

I know that I am late. I apology for not using MorphOS earlier ;-) I much prefer pasm/vlink over the GNU tools thus I am likely to spot such issues.

Quote:

Quote:

FWIW, its possible to use less assembly.

For __dbsize() then I guess...

Correct. And for access of __r13_init.

Code:
```
static __inline int __dbsize(void) {
  extern APTR __sdata_size, __sbss_size;
  static const ULONG size[] = {
    (ULONG)&__sdata_size, (ULONG)&__sbss_size,
  };
  return size[0] + size[1];
}

extern const char __r13_init;
const char *r13 = &__r13_init;
```
As a bonus that works for VBCC and GCC schedules the generated code ;-)
»13.04.06 - 09:38

CISC

# 40
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

Do you know if there are additional changes for binutils and gcc in CVS compared with the zapek releases?

Yes, there are quite alot, mostly for AltiVec, but also several bugfixes (some for the AltiVec patches themselves though)...

Quote:

There is another change in rs6000_encode_section_info that looks suspicious because it changes data access for SDATA_SYSV. The data is placed in .sdata but it gets accessed absolute (ha/l relocs).

Hmmm, I'm not sure what you're referring to, I can't see anything in that function regarding that.

Quote:

When using -mbaserel32 the symbols are still emitted as commons but this time the linker doesn't complain. Thus there must be a difference but I don't know where to look. FWIW, vlink works.

The difference is that -mbaserel32 can relocate from .comm, -mbaserel can't, and it seems that -mbaserel is fubar since it puts uninited global variables in .comm. :P

Quote:

Do you happen to know if the MorphOS ELF loader puts section .sbss directly after .sdata in memory? What about PowerUp?

In MorphOS those sections are indeed joined (also for PowerUP binaries), however I don't know if that's the case under AOS PUP...

Quote:

And for access of __r13_init.

Ah, indeed, didn't remember that bit of asm. ;)

- CISC
»13.04.06 - 15:57

munk

# 41
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
there are quite alot ("changes in CVS"), mostly for AltiVec, but also several bugfixes (some for the AltiVec patches themselves though)...

Yeah, the motorola GCC patches had some flaws. Well, despite the Altivec changes I have a problem with my MOS-GCC. The generated (native-)assembler is broken - it doesn't handle string escapes correctly :-( That happens without and with the AltiVec patch.

Quote:

Hmmm, I'm not sure what you're referring to, I can't see anything in that ("rs6000_encode_section_info") function regarding that.

I am talking about the "size <= g_switch_value" test. It was an independent test but now its wrapped into other tests that prevent that the if is taken. This changes behaviour and I don't think its correct.

Quote:

The difference is that -mbaserel32 can relocate from .comm, -mbaserel can't

Then its a ld bug IMHO ;-)

Quote:

it seems that -mbaserel is fubar since it puts uninited global variables in .comm. :P

Thats fine and normal. The same happens for -mbaserel32 (objdump --syms shows that).

Quote:

Quote:

Do you happen to know if the MorphOS ELF loader puts section .sbss directly after .sdata in memory? What about PowerUp?

In MorphOS those sections are indeed joined (also for PowerUP binaries), however I don't know if that's the case under AOS PUP...

Thanks for this information about MOS. I would guess that AOS PUP does the same.
»18.04.06 - 11:41

CISC

# 42
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

The generated (native-)assembler is broken - it doesn't handle string escapes correctly

Examples?

Quote:

This changes behaviour and I don't think its correct.

Hm, possibly, I'm not familiar with that part of the patch .. Emm would know more than I do about that...

Quote:

Then its a ld bug IMHO

Well, not quite.

Quote:

Thats fine and normal. The same happens for -mbaserel32 (objdump --syms shows that).

Sure, but -mbaserel32 isn't limited in the same way. Anyway, according to Emm -mbaserel is broken in other ways as well, so infact it was never really supported, sorry for inadvertently misleading you. :P

- CISC
»18.04.06 - 13:33

munk

# 43
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
Quote:

The generated (native-)assembler is broken - it doesn't handle string escapes correctly :-(

Examples?

Here is an example: '.string "\251"'. My custom cross-build MOS-native 2.9.1 gas emits a zero and then 251 but it should emit 0xA9.Thus something got miscompiled. I tried several optimization levels but the bug remained. I didn't test without optimization :-P

Quote:

Quote:

This changes behaviour and I don't think its correct.

Hm, possibly, I'm not familiar with that part of the patch .. Emm would know more than I do about that...

For now I changed that part and made it conditional on BREL mode. That restores the original behaviour but keeps the BREL sematic.

Quote:

according to Emm -mbaserel is broken in other ways as well, so infact it was never really supported, sorry for inadvertently misleading you. :P

Its enough to know that it doesn't work with GNU-ld. It works quite well with vlink.

BTW, I noticed another "problem" with the barfly objects from libabox.a: their .comment section type is "SHT_NOTE", but GAS created objects use PROGBITS.
»18.04.06 - 16:14

CISC

# 44
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

Here is an example: '.string "\251"'. My custom cross-build MOS-native 2.9.1 gas emits a zero and then 251 but it should emit 0xA9.

Indeed, however shouldn't that be \0251 (no matter, miscompiles too)? Interestingly enough \xa9 works...

Quote:

Its enough to know that it doesn't work with GNU-ld. It works quite well with vlink.

I wouldn't rely on that though, like I said, according to Emm it's broken in other ways.

Quote:

BTW, I noticed another "problem" with the barfly objects from libabox.a: their .comment section type is "SHT_NOTE", but GAS created objects use PROGBITS.

Thanks for checking, but I doubt laire can be bothered to dig up basm sources to change that. :P

- CISC
»18.04.06 - 20:38

munk

# 45
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
Quote:

Here is an example: '.string "\251"'. My custom cross-build MOS-native 2.9.1 gas emits a zero and then 251 but it should emit 0xA9.

Indeed, however shouldn't that be \0251 (no matter, miscompiles too)?

With zero I meant a binary zero '\0', not the number '0'. Do I understand that correctly that you get the same result as me? Bummer... Well, I checked with the zapek binutils release and that assembler works, i.e. it does emit 0xA9 for the octal-escape. Then I used his GCC sources to build a cross-compiler and then used that compiler to build the native gas. Unfortunately, nothing changed (the assembler is still broken) :-/

I just did another test: I build my cross-compiler without optimization and compared its output when compiling binutils with the one build with optimization. There is no difference for GAS. That seems to indicate a generic GCC problem.

Quote:

Interestingly enough \xa9 works...

I forgot to check that myself... but thats a different escape and handled by different code. You can find the string escape handling in gas/read.c/next_char_of_string. GCC always emits octal-escapes (gcc/config/svr4.h/ASM_OUTPUT_LIMITED_STRING) and the compiler converts hex-escapes in strings to octal-ones.

Quote:

Quote:

Its enough to know that it doesn't work with GNU-ld. It works quite well with vlink.

I wouldn't rely on that though, like I said, according to Emm it's broken in other ways.

He is probably talking about GNU-ld and not about the compiler. I am using SDATA_SYSV for some time (I added __saveds support to my powerup gcc) and it works pretty solid. FWIW, I am using it to compile mpega_libmad for PowerUp.

Quote:

Quote:

BTW, I noticed another "problem" with the barfly objects from libabox.a: their .comment section type is "SHT_NOTE", but GAS created objects use PROGBITS.

Thanks for checking, but I doubt laire can be bothered to dig up basm sources to change that. :P

Thats unfortunate, really :-/ These objects have another flaw: their .text section has SHF_WRITE set in sh_flags but .text isn't writable. Its really annoying to see how lenient GNU-ld is :-( Until a proper solution is available (new SDK ;-) I decided to patch away all deficiencies in the libraries. Now vlink likes them :-)
»19.04.06 - 13:33

CISC

# 46
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

Do I understand that correctly that you get the same result as me? Bummer...

Yes. :P

Quote:

Well, I checked with the zapek binutils release and that assembler works, i.e. it does emit 0xA9 for the octal-escape. Then I used his GCC sources to build a cross-compiler and then used that compiler to build the native gas. Unfortunately, nothing changed (the assembler is still broken)

Uhm, which binutils is this? Anyway, I would guess chances are that that binutils was built by another (probably older) GCC...

Quote:

I just did another test: I build my cross-compiler without optimization and compared its output when compiling binutils with the one build with optimization. There is no difference for GAS. That seems to indicate a generic GCC problem.

I did my own research, and it is indeed a GCC bug, it miscompiles the for-loop .. until the bug is fixed I worked around it with a while-loop...

- CISC
»20.04.06 - 02:29

munk

# 47
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
Uhm, which binutils is this?

Its 2.9.1 with MOS patches that are based on the last zapek binutils version. I removed all superfluous stuff (eg. the bits that caused mysterious "malformed archive", AmigaOS/68k support, etc.) and polished the rest a bit. I did not touch bfd/elf32-morphos.c ;-)

Quote:

Anyway, I would guess chances are that that binutils was built by another (probably older) GCC...

If its a generic GCC 2.95.x bug I wonder how he was able to produce working code.

Quote:

I did my own research, and it is indeed a GCC bug, it miscompiles the for-loop .. until the bug is fixed I worked around it with a while-loop...

If you have a fix, please make it available (together with all other fixes you might have).
»20.04.06 - 08:38

CISC

# 48
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

Its 2.9.1 with MOS patches that are based on the last zapek binutils version.

But what is the "last zapek binutils version"? The one that was on morphos.org?

Quote:

If its a generic GCC 2.95.x bug I wonder how he was able to produce working code.

Either by sheer luck, or by compiling without -O2 .. the thing that tips the scale either way on this bug is the complexity of the isdigit() macro...

Anyway, AFAIK none of the publically released binutils have this issue, I only happened to reproduce it now due to updated isdigit() macro and rebuilding binutils with full optimizations after your other bugreports. ;)

Quote:

If you have a fix, please make it available (together with all other fixes you might have).

Well, there is no fix for this bug yet (and it seems abit awkward to track (I have produced a quite narrow testcase now though)), the only thing you can do is either workaround it with a while-loop or compile read.c without -O2 (or alternatively undefine the isdigit() macro)...

As for other fixes they will have to wait until we release a new SDK as I don't fancy trying to untangle them from the AltiVec stuff (and apart from the "malformed archive" thing I can't specifically recall which fixes there has been (tons of CVS history have been lost thanks to Zapek)).

- CISC
»20.04.06 - 22:57

munk

# 49
Butterfly

Posts: 94 from 2006/3/27

Quote:

CISC wrote:
But what is the "last zapek binutils version"? The one that was on morphos.org?

I have no idea what was on morphos.org. The sources I used as one reference can be found here: binutils/gcc. The other sources used were obtained from Martin Bloms site. Additionally I had a GCC diff from morphos.org and it looks like that Martin Blom based his MOS support on that diff.

Quote:

Either by sheer luck, or by compiling without -O2 ..

I didn't try without optimization, but it breaks with -O/-O1 as well.

Quote:

I only happened to reproduce it now due to updated isdigit() macro and rebuilding binutils with full optimizations after your other bugreports. ;)

Then it was worth the time I invested :) I wish I would have mentioned the gas problem earlier but I didn't expected to face a compiler problem there, thus I thought its all my fault...

Quote:

As for other fixes they will have to wait until we release a new SDK as I don't fancy trying to untangle them from the AltiVec stuff

I could do that since I have done something similiar with zapek binutils/GCC where I separated AltiVec from the MOS patches. That way its much easier to work on these packages. It does also ease a possible port to newer toolchains. Maybe it would be a good idea to start a new CVS from virgin sources and apply only those changes that are required. I can provide my work if that helps.

About a new SDK: is it possible to fix libabox.a without barfly? I guess all broken sources are written in assembly, right? Then pasm should be able to assemble them.

And another issue (sorry ;): I believe it was unfortunate that MOS based their includes on the GG headers. These are very 68k centric, which is IMHO a major pain. I removed/replaced some headers to get rid of such stuff. The changed machine/ansi.h is a major headache since it uses _G_config.h to specify basic types. When building libstdc++ I noticed re-define warnings. I tried to remove these by forcing the GCC stddef.h to include machine/ansi.h but that breaks because of the SDK changes :-/ To resolve that issue reverted the changes in machine/ansi.h and used a different approach for _BSD_VA_LIST_.
»21.04.06 - 10:04

CISC

# 50
MorphOS Developer

Posts: 619 from 2005/8/27

From: the land with ...

Quote:

The sources I used as one reference can be found here: binutils/gcc.

Oh dear, I wasn't aware of this one .. yet another silly zapek-idea...

Funny how he claims there's no issues with it since there were several known issues with it when it still was on Zapek's CVS, ranging from bad stack-alignment to ICEs (and C++ doesn't even work like he claims (atleast not when you use -fvec)) (hey, I guess I do remember some fixes we did. ;) ), even funnier how he goes on attacking some poor innocent (ok, I don't know exactly what the claims were (since he provides no links)) person for claiming it wasn't bug-free...

Quote:

I didn't try without optimization, but it breaks with -O/-O1 as well.

That's odd, works fine with -O1 here .. tried #undef isdigit?

Quote:

I could do that since I have done something similiar with zapek binutils/GCC where I separated AltiVec from the MOS patches.

Sure, if you want to work on that it would be great, esp. if you provided an intermediate "unofficial" update for our SDK until we can ship the new one with AltiVec stuff (always happy to delegate work). ;)

Quote:

Maybe it would be a good idea to start a new CVS from virgin sources and apply only those changes that are required. I can provide my work if that helps.

Possibly, anyway, I'll mail you and we'll continue the discussion from there...

Quote:

is it possible to fix libabox.a without barfly? I guess all broken sources are written in assembly, right? Then pasm should be able to assemble them.

Yeah, obviously it's in asm. ;) I guess some of it could be modified to use gas, I have no clue about pasm...

Quote:

I believe it was unfortunate that MOS based their includes on the GG headers. These are very 68k centric, which is IMHO a major pain.

Yeah, the 68k junk is abit annoying. ;) ..but it should be obvious why we based them on the GG ones (the cleanup work could have been abit more thorough though (but hey, who am I to talk?)). :P

- CISC
»21.04.06 - 22:36