English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 27 October 2014, 21:46   #1
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 40
Posts: 1,404
News about AROS 68k development?

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]

Last edited by Photon; 14 November 2014 at 23:53.
Leandro Jardim is offline  
Old 28 October 2014, 00:04   #2
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 2,012
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
gulliver is offline  
Old 28 October 2014, 01:29   #3
Leandro Jardim
Registered User
Leandro Jardim's Avatar
 
Join Date: Nov 2009
Location: Legoland
Age: 40
Posts: 1,404
Quote:
Originally Posted by gulliver View Post
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 )
Leandro Jardim is offline  
Old 28 October 2014, 08:59   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,356
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.
Toni Wilen is offline  
Old 28 October 2014, 15:58   #5
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 48
Posts: 1,838
Have you tried LLVM with a 68k backend?
http://sourceforge.net/projects/llvm68k/
IFW is offline  
Old 28 October 2014, 17:24   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,356
I am 100% sure it won't work, AROS uses GCC extensions heavily. (and I don't do compiler stuff)
Toni Wilen is offline  
Old 29 October 2014, 00:40   #7
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
Quote:
Originally Posted by Toni Wilen View Post
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:
Quote:
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.
wawa is offline  
Old 29 October 2014, 11:31   #8
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
Quote:
Originally Posted by Toni Wilen View Post
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:
Code:
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.
Leffmann is offline  
Old 29 October 2014, 11:46   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,356
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 is offline  
Old 29 October 2014, 12:04   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,356
Quote:
Originally Posted by wawa View Post
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.
Toni Wilen is offline  
Old 29 October 2014, 13:22   #11
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 29 October 2014, 13:45   #12
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
note discussion with heiroglyph and thor here:
http://www.amiga.org/forums/showthre...=67649&page=14
heiroglyph:
Quote:
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 is offline  
Old 29 October 2014, 13:49   #13
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
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?
wawa is offline  
Old 29 October 2014, 14:07   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,356
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.
Toni Wilen is offline  
Old 29 October 2014, 14:15   #15
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
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 is offline  
Old 29 October 2014, 17:29   #16
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
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)
wawa is offline  
Old 29 October 2014, 18:29   #17
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 289
Quote:
Originally Posted by wawa View Post
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.
BSzili is offline  
Old 29 October 2014, 18:44   #18
OlafSch
Registered User
 
Join Date: Nov 2011
Location: Nuernberg
Posts: 531
Quote:
Originally Posted by Toni Wilen View Post
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?
OlafSch is offline  
Old 29 October 2014, 18:48   #19
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,041
@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.
wawa is offline  
Old 29 October 2014, 18:48   #20
OlafSch
Registered User
 
Join Date: Nov 2011
Location: Nuernberg
Posts: 531
Quote:
Originally Posted by BSzili View Post
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.
OlafSch is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
AMOS for Windows installer using AROS-68K and WinUAE Mequa News 32 04 May 2017 10:08
New Video of my Aros 68k distribution "Aros Vision" OlafSch Amiga scene 26 16 February 2016 12:16
How do I create an AROS 68k boot disk? Leandro Jardim Amiga scene 3 18 October 2014 04:37
News about Aros Vision OlafSch Amiga scene 3 09 June 2014 16:04
Version 1.3. of Aros Vision 68k online now OlafSch Amiga scene 1 19 June 2012 14:43

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09041 seconds with 13 queries