What is currently still missing in SDCC that would be needed or desired
to make SDCC a better replacement for the Small-C-based compiler in z88dk?
Philipp
[z88dk-dev] What' still missing in SDCC
What is currently still missing in SDCC that would be needed or desired
to make SDCC a better replacement for the Small-C-based compiler in z88dk?
I don't think anything is missing actually. What we have now with the new c library is pretty much a perfect integration. Down the road there might be something with bankswitching but that's an issue that won't come up for a while. Maybe the only problem is we still need a relatively minor patch to make sdcc compatible. If you remember, regression tests on other uPs failed with the current patch so it could not be fully integrated into sdcc. But that's probably more on us to figure out why the failures occur. One other minor change I made to the "peep.c" since then is this:
@@ -999,7 +1000,8 @@
/* If the instruction is unrecognized, we shouldn't try to optimize. */
/* For all we know it might be some .ds or similar possibly long line */
/* Return a large value to discourage optimization. */
- werrorfl(pl->ic->filename, pl->ic->lineno, W_UNRECOGNIZED_ASM, __FUNCTION__, 999, pl->line);
+ //werrorfl(pl->ic->filename, pl->ic->lineno, W_UNRECOGNIZED_ASM, __FUNCTION__, 999, pl->line);
+
return(999);
I was experimenting with pseudo-opcodes in the peephole rules and a segmentation fault occasionally occurred in the werroffl() call. The instruction(s) encountered were fake and introduced by the peephole rules themselves so I think some of that structure was uninitialized (there might not have been an associated line number, eg) and set to NULL which caused seg faults on dereferencing.
On the classic c library side, sdcc supplies the smallc attribute to allow function linking using L->R parameter order. But I think the correct way to do things, although it is more work, is to do what is done in the new C library. That is, completely separate the asm implementation with register interface and then supply different C preambles that jump to the asm implementation that take care of fastcall, callee, R->L, L->R linkages. Some of the work is done -- the classic C library can just use the new C library's string, stdlib, etc functions. But there's still a large body of classic c lib code in graphics especially that would need this work.
------------------------------------------------------------------------------
Ah, yes, there is a mismatch in the float types but I agree with what you wrote on the sdcc list -- having the ability to support varied float types from the compiler side is low priority.
The new c library can plug in any floating point backend on the compile line. "-lm" currently connects math48 to the compilers which is a 48-bit float type with 40 bits mantissa. What happens with sdcc is that we automatically convert between this 48-bit type and the 32-bit format sdcc expects at the library/compiler interface by truncating the extra mantissa bits. The 48-bit float type is special for the z80 because it is the largest float type that can be done in registers without resorting to memory to store one operand. A 32-bit type may also be special as you can deal with it just like a long and hold two operands in registers at the same time. So I think in z88dk's case having a native z80 32-bit float type might be a beneficial idea in the future if anyone feels motivated to do it. In the benchmarks, Hitech CPM (if you ignore some of the accuracy issues) actually beats us on speed because it has a smaller float type.
Then there's the need for a fast float/fixed point type for the graphics library. I'm not sure what the characteristics will be yet. In the absence of direct compiler support it will probably be wrapped inside an integer. Lastly there is an arbitrary precision math library available based on bcd which we may look at too. It only has basic functionality so it would require a lot of work to add expected functionality.
On top of these things, many targets supply native floating point implementations and using them gets floating point essentially for free in terms of binary size. The classic c library can use the native float implementation for two targets and the new c library can do the same simply by linking against a math library that converts between the float types expected by the compiler and by the native implementation. The formats are varied so dealing with them is probably best done with runtime conversion.
As I said, compiler support for multiple float types is low priority on the z80 but in case you ever think about it, this is food for thought.
------------------------------------------------------------------------------
The new c library can plug in any floating point backend on the compile line. "-lm" currently connects math48 to the compilers which is a 48-bit float type with 40 bits mantissa. What happens with sdcc is that we automatically convert between this 48-bit type and the 32-bit format sdcc expects at the library/compiler interface by truncating the extra mantissa bits. The 48-bit float type is special for the z80 because it is the largest float type that can be done in registers without resorting to memory to store one operand. A 32-bit type may also be special as you can deal with it just like a long and hold two operands in registers at the same time. So I think in z88dk's case having a native z80 32-bit float type might be a beneficial idea in the future if anyone feels motivated to do it. In the benchmarks, Hitech CPM (if you ignore some of the accuracy issues) actually beats us on speed because it has a smaller float type.
Then there's the need for a fast float/fixed point type for the graphics library. I'm not sure what the characteristics will be yet. In the absence of direct compiler support it will probably be wrapped inside an integer. Lastly there is an arbitrary precision math library available based on bcd which we may look at too. It only has basic functionality so it would require a lot of work to add expected functionality.
On top of these things, many targets supply native floating point implementations and using them gets floating point essentially for free in terms of binary size. The classic c library can use the native float implementation for two targets and the new c library can do the same simply by linking against a math library that converts between the float types expected by the compiler and by the native implementation. The formats are varied so dealing with them is probably best done with runtime conversion.
As I said, compiler support for multiple float types is low priority on the z80 but in case you ever think about it, this is food for thought.
------------------------------------------------------------------------------