View Single Post
Old 21 May 2016, 00:00   #9
Registered User
Join Date: Jun 2010
Location: USA
Posts: 69
Originally Posted by matthey View Post
CGFX/P96 patched everything at least because of the following problems.

1) graphics.library is in ROM
2) they didn't want to recreate the low level Amiga chipset support

The result is a patching nightmare but it does work better than I ever thought it would have (both CGFX and P96 work and are stable on a wide range of Amigas). If wanting to create a better replacement, then it would be good to create a whole new graphics.library IMO. Leaving out the custom chipset hardware banging gets you what AROS has now. Including it has two big issues.

1) C is probably not going to give the best code quality on the 68k
2) changing the hardware banging chipset code could cause compatibility problems and not changing them could violate copyrights

I support most of your conclusions about how to go about improving/replacing the AmigaOS but it is a difficult task with all the road blocks. There isn't a modern compiler which generates good quality code for the 68k, including vbcc. Yes, it has potential and I have worked on it myself (bug fixes, ease of use, inlines, vclib code, better C99 support, improved FPU support, better GCC compatibility with builtin.lib, etc). I had a conversation with Frank Wille recently about improving the code generation. I told him that old CPU targets like the 68k are unlikely to get improved support without new hardware and standards (Volker may still make some improvements).
My plan is to start by patching in anyway.

I assumed I'd start one entry point at a time.
Write a work-alike (as much as is feasible)
Run a test app that makes some test calls, patches in my replacement, then makes the same test calls again and compare the result.

That will pretty quickly tell me where there is internal data and I can potentially put off the chipset functions until later.

The chipset parts are mostly available in Aros from what I understand though, they're just slow. They might want some of this code if we can improve 68k performance. It is the only platform I'm targeting with this, so it will have to be reasonably fast or else be rewritten.

I want to stick with C because ASM isn't clear enough for most people to contribute or even just read.

I'm confident that it will be fast enough for the most part with only certain sections needing optimizations in assembly.

Is there a compiler that you feel produces better code and is still well supported?

If not, I like the idea of vbcc because it's better integrated with the platform, still developed, open source and the developers are a known quantity.
Heiroglyph is offline  
Page generated in 0.06852 seconds with 9 queries