From: Bernhard H. <bh...@mg...> - 2004-06-21 11:43:39
|
> I've got a low-priority RFE I just tried to get better bit-banging code out of sdcc. It's not too difficult to avoid promotion from bit to char in AST at several places. But iTemps in iCode of type bit are always promoted to char, which renders all my efforts useless. IMHO iTemps of type bit make sense (at least for mcs51). But I've not yet an idea how to implement them. The default location of a iTemp is a registers or a spill-location. The mcs51 isn't very effective in manipulating bits at these places. Or should the bit-iTemps be moved to the bit-addressable area? This arises the next problem: what to do if we're out of bit memory? Any ideas? Comments? Bernhard P.S.: load/store carry from/to iTemp in register save_cy: mov iTemp,psw ; save cy whith whole psw to iTemp restore_cy: mov a,iTemp rlc a |
From: Erik P. <epe...@iv...> - 2004-06-21 21:49:48
|
On Mon, 21 Jun 2004, Bernhard Held wrote: > > I've got a low-priority RFE > I just tried to get better bit-banging code out of sdcc. It's not too > difficult to avoid promotion from bit to char in AST at several places. But > iTemps in iCode of type bit are always promoted to char, which renders all > my efforts useless. > > IMHO iTemps of type bit make sense (at least for mcs51). But I've not yet an > idea how to implement them. The default location of a iTemp is a registers > or a spill-location. The mcs51 isn't very effective in manipulating bits at > these places. Or should the bit-iTemps be moved to the bit-addressable area? > This arises the next problem: what to do if we're out of bit memory? > > Any ideas? Comments? > > Bernhard > > > P.S.: load/store carry from/to iTemp in register > > save_cy: > mov iTemp,psw ; save cy whith whole psw to iTemp > > restore_cy: > mov a,iTemp > rlc a Starting with bug #938782 "Problems with bit vars as arguments", I've been contemplating adding _Bool as another type so that boolean values can be coherently passed around in bytes. This type would have some additional specifier flags that indicate the value's representation. At the moment, there are two ways boolean values are stored in bytes: 1) the value 0 or 1, or 2) a zero or non-zero value Code that assumes an input operand of form #1, but receives form #2 will generate incorrect results (bug #938782). It is always safe to assume form #2, but usually leads to inefficient code. If we know the format, we could always do the most efficient conversion (or just skip the conversion). Your idea for storing the whole psw could be a third format. If you are dealing with two iTemps in this format, the &, |, ^ operators can be applied to the whole byte to yield the correct result (still in this format); converting back to a bit need only occur for the final result. If you are dealing with one iTemp in this format and another as a bit, put the bit in carry and the iTemp in A; the iTemp's bit is then bit addressable as ACC.7 (or ACC.0, if the iTemp was in form #1). My rationale for adding _Bool rather than just modifying the bit type was to 1) avoid unforseen behavior in the existing bit logic, and 2) continue moving towards the current standard. However, we could probably still use this strategy (of noting the current format) with the bit type as long as it is in an iTemp. Erik |