News about AROS 68k development?

[Leandro Jardim]

Is there a place for AROS 68k news? Will the OCS/ECS/AGA graphics routines be optimized someday? Is there a prevision for that?

[Found this: http://eab.abime.net/showpost.php?p=...postcount=355]

[gulliver]

I am sorry to tell you that as far as I know Aros68k is still as bloated for real Amigas as an off season bodybuilder

[Leandro Jardim]

Originally Posted by gulliver

I am sorry to tell you that as far as I know Aros68k is still as bloated for real Amigas as an off season bodybuilder

Oh, so I think that it will not work for me. (both AROS 68k and the bodybuilder )

[Toni Wilen]

It is not going to get any better until (and not worth the trouble to even attempt to optimize anything):

a) gcc gets better m68k code generation and also includes support for register parameters directly.
b) some other compiler becomes close-enough-gcc-compatible.

[IFW]

Have you tried LLVM with a 68k backend?
http://sourceforge.net/projects/llvm68k/

[Toni Wilen]

I am 100% sure it won't work, AROS uses GCC extensions heavily. (and I don't do compiler stuff)

[wawa]

Originally Posted by Toni Wilen

I am 100% sure it won't work, AROS uses GCC extensions heavily. (and I don't do compiler stuff)

has that to do with this here?

http://aros-exec.org/modules/newbb/v...C&type=&mode=0

staf:

But also that my vision on abiv0/abiv1 seems to be different than the rest of the AROS devs together with my vision on the hacks present in the AROS source code for m68k compatibility.

the gcc 68k adaptation was mostly jasons work, right? as i understand it has not been done properly, but bieen rather an intermediate solution to get it working as prood of concept. alas staf disengaged with aros as it seems and there is none who is interested and able to work on 68k backend.

[Leffmann]

Originally Posted by Toni Wilen

It is not going to get any better until (and not worth the trouble to even attempt to optimize anything):

a) gcc gets better m68k code generation and also includes support for register parameters directly.

GCC does support register-mapping for parameters so you can do short Amiga system calls (I assume that's what you want), but the syntax is messy and you would have to auto-generate it from the function descriptor files:

static __inline__ void* OpenLibrary(const char* l, int v)
{
  register void* __base __asm__("a6") = SysBase;
  register const char* __l __asm__("a1") = l;
  register void* __vr __asm__("d0") = (void*)v;
  __asm__ volatile ("jsr -552(%%a6)"
                   : "=d" (__vr)
                   : "a" (__base), "a" (__l), "d" (__vr)
                   : "d1", "a0", "cc"
                   );
  return __vr;
}

All the details are in the GCC manual.

[Toni Wilen]

AROS m68k uses the messy way (ugly macros and inline assembly) but I wouldn't call it "supported". Anything can be "supported" with inline assembly.

But as I said, I don't do compiler stuff and as long as compiled result is as bad as it is currently, there is no point to optimize anything non-obvious.

[Toni Wilen]

Originally Posted by wawa

the gcc 68k adaptation was mostly jasons work, right? as i understand it has not been done properly, but bieen rather an intermediate solution to get it working as prood of concept. alas staf disengaged with aros as it seems and there is none who is interested and able to work on 68k backend.

Yes and I don't think there is any "production quality" solutions with current m68k GCC. It would not be accepted to mainline and would stay a unsupported hack forever.

Also m68k aros bounty 2 specifically said result must be rommable on real hardware. It can't have bss or data sections, at least without compiler understanding Amiga-specific special requirements for creating rommable bss/data.

[wawa]

Originally Posted by Toni Wilen

Yes and I don't think there is any "production quality" solutions with current m68k GCC. It would not be accepted to mainline and would stay a unsupported hack forever.

Also m68k aros bounty 2 specifically said result must be rommable on real hardware. It can't have bss or data sections, at least without compiler understanding Amiga-specific special requirements for creating rommable bss/data.

i imagine that it will probably not get accepted upstream, but is there a particular reason, why we expect that? is that because amiga-m68k is an obsolete target with no significant audience?

the question is, what to do, if we take the above for granted? we can either give up on aros or think of some way to make the improvement happen and how it might get maintained even without being pushed updstream into the mainline. the bad thing is, you are not into the compiler work, staf would only supervise and guide if someone else would pick up the task and jason has almost left as it seems, doing only ocassional delints now and then, how he used to.

there seems also to be a disagreement in aros dev team as how to approach it. i didnt exactly understand, who is opposing staf and what is the problem. perhaps the issue is the x86 backward compatibility, and therefore the recent effort deadwoods to adopt v1 changes to v0. seems this might be the issue. they got stuck half a way, cant decide to move forward, cant decide to drive back home. its really bad they dont discuss it properly, well maybe they do but only in the ml, i have given up on.

[wawa]

note discussion with heiroglyph and thor here:
http://www.amiga.org/forums/showthre...=67649&page=14
heiroglyph:

I think Thomas is right on the money about startup and C library code.

My guess is that there's about 2k of startup/clib code duplicated on each command, but it may also be gcc contributing.

Most of my changes involved using native methods that would be in ROM, doing my own startup (2-3 lines of C code, wouldn't work in x86 AROS) and using C that I knew would compile to better assembly.

IMHO it's more readable now and I fixed several bugs along the way. AROS AddBuffers for example won't work correctly on a real ROM, but this works on both back to v37 KS.

I had more of it done with SAS/C but switched to vbcc this weekend for c99 support and a better compiler.

he actually might be a candidate to contribute to amiga-m68k branch of aros, as he says he has startup code and the like, so he might introduce vbcc compatibility. yet he seems to have switched to mos lately and aros looks probably for more general solution, and anytjing like that would end up as a fork and not in the main maintained repository, best case.

[wawa]

so long story short: where to look for someone who might fix it for us? ;P

any ideas, or do we need to put aros back on the shelves for the time being?

[Toni Wilen]

First major step (before even attempting to think about other problems) is to get supported tool chain (compiler/linker/stuff) that is m68k and amiga OS ABI friendly. For example knows what to do with library base, A6 register. Without ugly hacks. It must "just work". We are trying to develop stuff, not fight with tools that are normally supposed to make it easier and faster.

Getting aros to build with both gcc and some other compiler probably will be the biggest problem. Non-m68k developers surely don't want to switch whole tool chain which "just works" with other platforms.

GCC has obsoleted lots of old platforms in recent years.

[wawa]

so you are saying that gcc support for amiga-m68k would have to be oficially maintained again? but you said before it was unrealistic?

while i also expect that aros developers will sure not give up gcc for anything else, they might accept to accomodate changes to make aros vbcc compilable. the problem is the amount of changes across the code i guess? the different asm inlining convention being one of the issues?

[wawa]

since i have an imprecssion this is not an issue that can be solved for 68k exclusively and would need a consens with the whole aros team i posted an inquiry on aros-exec:
http://aros-exec.org/modules/newbb/v...forumpost90807

(for better or worse)

[BSzili]

Originally Posted by wawa

perhaps the issue is the x86 backward compatibility, and therefore the recent effort deadwoods to adopt v1 changes to v0. seems this might be the issue. they got stuck half a way, cant decide to move forward, cant decide to drive back home. its really bad they dont discuss it properly, well maybe they do but only in the ml, i have given up on.

x86 ABIv1 is not meant to be backwards compatible with x86 ABIv0, and the two being separate branches, deadwood's backport had no direct influence ABIv1. All it did was pushing out the lifespan of ABIv0.
One could argue that this takes away the focus from ABIv1, but the biggest problem is really the lack of developers. It doesn't really matter whether the users are interested in ABIv1 or not, until it's finished. It was mostly staf working on it, and he got a little discouraged over the years. He tried to recruit other people to work on it, he even gave a list of what needs to be done, but no one was up to the job.

[OlafSch]

Originally Posted by Toni Wilen

First major step (before even attempting to think about other problems) is to get supported tool chain (compiler/linker/stuff) that is m68k and amiga OS ABI friendly. For example knows what to do with library base, A6 register. Without ugly hacks. It must "just work". We are trying to develop stuff, not fight with tools that are normally supposed to make it easier and faster.

Getting aros to build with both gcc and some other compiler probably will be the biggest problem. Non-m68k developers surely don't want to switch whole tool chain which "just works" with other platforms.

GCC has obsoleted lots of old platforms in recent years.

If I understand you right building a own fork based on another compiler would be the only realistic chance to move forward?

[wawa]

@bszili

im not saying v0 is pulling the development resources from v1, at least not directly. i understand with v0 on trunk deadwood is dedicating himself to maintain an interim solution, because v1 would be binary incompatible, was taking too long time and in the meantime aros community has to relay on something to live on. this is not a bad idea at all. but i wonder if the result is that the dynamics necessary to put up with a jump towards v1 even more lost and we hang now in the mid air.

said that, the priority should probably be taking care of the rest of minor bugs in userland to make aros user attractive, then reaching full v1 probably along the staf and tonis postulates, and then first more platforms and software.

the question is where to find some equivalkent of jason and staf to take care of kernel and compilers.

[OlafSch]

Originally Posted by BSzili

x86 ABIv1 is not meant to be backwards compatible with x86 ABIv0, and the two being separate branches, deadwood's backport had no direct influence ABIv1. All it did was pushing out the lifespan of ABIv0.
One could argue that this takes away the focus from ABIv1, but the biggest problem is really the lack of developers. It doesn't really matter whether the users are interested in ABIv1 or not, until it's finished. It was mostly staf working on it, and he got a little discouraged over the years. He tried to recruit other people to work on it, he even gave a list of what needs to be done, but no one was up to the job.

68k is not their main interest anyway (or better not at all). If it could develop on its own with developers behind I would be happy. The Aros devs do not see the potential of 68k for Aros, they only see it as a addon, a mean to improve compatibility for 3.1. API implementation. If it would be its own fork with a group of dedicated developer behind there would be a huge potential for it.