Of course, there will be a need for a 050.library, a new graphic.library who will take advantage of SAGA and certainly a new and enhanced scsi.device...

Perhaps we could start with a list of what is actualy implemented on AROS 68k...

SCSI.device has been replaced by ATA.device in current versions of AROS.

@Thread

Hopefully the changes Mike Ness made to LLVM for AROS-Clang will someday trickle down to the NatAmi since we're both team members at this point.  Let's not worry about optimizations at this point with regards to compilers.

/me digs... I am mistaken, they have their own thing. But writing an OpenPCI.library shim on top of it should be trivial.

Although I am not an official Mediator developer, I do have one, and once my A4000 is running, I should be able to figure out how they've set up the PCI interface.

The only 'hard' part about most 5v PCI chipsets is figuring out how to generate config cycles and map IRQs. Everything else is just address mapping.
   

Matt Hey wrote:

Have you tried the new vbcc 0.9b? It has better C99 support now. Frank Wille has said he will add support for the N680x0 in his vasm assembler (used in vbcc). ColdFire optimizations already exist for it and could be done without support in vbcc itself. Frank provides great support if you can give details on what you need in AROS. The GCC developers are just not interested in supporting the 68k or Amiga and it shows. This leaves vbcc and LLVM/Clang (when it gets 68k support) for cross platform compiling.

Given the HUGE number of GCCisms that AROS uses, I think LLVM/CLang is a more likely candidate.

I did the exercise to try to get AROS to compile under vbcc, but I saw little significant difference in the generated code between it and gcc in what I was able to get to compile. Given the number of changes required to both AROS and vbcc to get AROS to compile under vbcc, I saw little reason to continue that project.

If someone else wants to take up the reigns and pick up where I left off, I still have my patches against vbcc to make things a little easier. My AROS patches have long since been made unusable by code changes.

This difference IMHO opinion is enough to make branch project for the ROM at least.(keeping it clean for both platforms)

as for what is the best compiler to port AROS i am not gonna stick my neck into that one. ;)

Yes, this make it (slightly) slower for all the non-m68k builds, but considering the MASSIVE room for improvements in the graphics.library, it's not noticeable due to the slowness of the UI. 

We do not yet have the resources (build and testing) to do per-CPU builds, which would achieve a number of the optimizations you are looking for.

What *would* greatly help is an open-source version of graphics.library that is optimized for the Amiga. Provide that, and Toni and I will be deeply in your debt.

This means we are both limited in type rate and scroll distance per second.
Then again this is no very interresting, does anyone know anyone who can type faster then 1/60 (1/50 PAL) of a second?

The above is only interresting when you have a high resolution even then the classic system caught the overrun in software.

For the natami this will be interesting with USB 1200DPI mouses and high resolutions.(nudge, nudge, bigger registers saves ya from overruns)

Back to topic, Jason it is a correct method with the current state of the hardware to support most important cpu's in a single build.(frankenstein amiga's all around)

Are there masochists that try to run AROS on 68000? I would think a 68020 target would be a better base as it has most of the improvements used in later CPUs and it's 32 bit at least. Would AROS lose more users from not supporting 68000 (for now) or from too slow of 68020+ code? 68000 is ok for now.

Jason S. McMullan wrote:

Yes, this make it (slightly) slower for all the non-m68k builds, but considering the MASSIVE room for improvements in the graphics.library, it's not noticeable due to the slowness of the UI.

Yea, fix or upgrade the algorithms first. Better compilers may come in the future. The AmigaOS uses mostly SAS/C with some of it still compiled for 68000 and has good performance. Of course, SAS/C and GCC 2.95.3 probably produce the best code on the Amiga.

Jason S. McMullan wrote:

What *would* greatly help is an open-source version of graphics.library that is optimized for the Amiga. Provide that, and Toni and I will be deeply in your debt.

Is the AROS graphics.library mostly bug free and the way it needs to be for chunky 16/24/32 gfx? Should planar gfx support go in the graphics.library? Where should ECS/AGA/SAGA hardware banging go (graphics.library, P96 .chip drivers, etc)? Is there a bit defined in the bitmap structure for chunky or planar detection like BMF_USERPRIVATE in P96 and BMF_SPECIALFMT in CGFX (should be bit 7, 15 or 31 for speed)? Does the AROS layers.library support planar? It may be premature to make an optimized version with planar support but I have an idea how I would do it to keep it "open source". It's a pretty big project though. I'll look into AROS some more and think about it but I have some other projects too.

Matt just because i use a A500 doesn't make me a Masochist. ;)

AROS has a built-in CGFX support and OCS/ECS/AGA planar support, with some blitter acceleration for AGA/ECS/OCS copybox. We're missing quite a bit though for planar fast blits, so a lot of operations end up going through the software stack.

AROS graphics is built upon oop.library, by the way.

I think the better question is if AROS will detect that there is no FPU in the 060 and set the ExecBase->AttnFlags correctly (!AFB_FPU40). Some programs may have problems with a 68060 without FPU anyway.

But Linux is opensource, So Perhaps the C code for the FPU emulator is out there somewhere...

There's no need to think bottom-up again except for graphics.library optimisation that could be done later.

I think you forgot to think about C++ which "improved" C or a better "C", like ComeauC++ or Cfront1.0 C++(available on the net) which is the same, I think, that what happens to BCPL code.

[But I'm really evaluating BCPL from a Virtual machine based language for AmigaDOS kind of Objective-BCPL!]

Seriously, I've done work on ExecC++ and I think AROS has already done this with Exec or on the RoadMap : not saw the AROS code.

Please consider a basic C compiler, like SAS and a better "C" for a programer (coder?) perspective as a Cfront1.0 with no template and no Exception (multiple heritage is 2.0).

Here's my contribution but in France and reworking must be done even it respect 680x0 ins/data alignment using _struct_ intead of _class_ when needed (no virtual table pointer).

EXTERNAL LINK 
Sincerely,

Gilles DRIDI - technician