View Single Post
Old 13 May 2017, 21:45   #236
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Originally Posted by gulliver View Post
CBM code was a mess, in that every AmigaOS developer used whatever C and ASM compiler they liked, and then they didnt follow any coding standard, so figuring what two different developers did, requires two totally different aproaches.

Backporting to a standard open source C compiler is a very good idea on AmigaOS components which are not speed or size constrained, which happens in many cases. But where speed and size efficiency are required, ASM is a must and now that PhxAss has become open source, it seems to be a very good candidate.
The code should be for a C standard (C89 but consider moving to C99) and not use compiler specific support without good reason. Vasm is also free but supported and is a better choice than PhxAss (default vasm mode is an enhanced Devpac syntax). It would be good to have most code in C but have exact replacement conditionally used assembler routines where there are improvements. Sometimes improvements in the C code can be found from optimizing the assembler output and can be used to improve the C code as well. Having good performance is important on low end 68k systems. AmigaOS 3.9 never really advanced to the optimization stage and it became a bit too heavy for low end users. Some parts of the AmigaOS need improvements before optimizing though. ThoR's layers.library is a good example of a CPU intensive library which has been improved and would benefit from optimization. My benchmarks were showing about 10% improvements on average using P96 Speed with a partial optimization job.

Originally Posted by gulliver View Post
Then it is pretty reasonable to start working with the core of AmigaOS, which happens to be in the kickstart. Wether those components should still remain in a rom is another matter alltogether.
Moving components out of kickstart would cause compatibility issues. Using compilers which generate better 68k code and optimizations could probably get components to fit in a 512kB kickstart again (10%-20% average size reduction is probably possible for kickstart components). New hardware should probably move to a 1MB kickstart. An enhanced 68k CPU could improve code density (reduce code size) another 5%-15% and make compiler support easier for code quality improvements, not that anybody cares about that but me. The whole kickstart can be write protected in memory giving some cheap partial memory protection. New hardware just needs flash MAPROM support. Of course, with the current situation it would probably be better to do something similar with AROS.
matthey is offline  
Page generated in 0.05036 seconds with 9 queries