On 04/11/2012 09:15 PM, Richard Sandiford wrote:
> Bernd Schmidt <ber...@codesourcery.com> writes:
>> On 04/11/2012 07:31 PM, Peter Bigot wrote:
>>> The biggest one is that widening from 20-bit to 32-bit is an extremely
>>> expensive operation: it was a 16-bit ISA, but some newer MCUs support
>>> an extension with 20 bits in each register and a set of new
>>> instructions that must be used to preserve the upper 4 bits.  Getting
>>> bits 19..16 of a 20-bit register down into the low bits of a 16 bit
>>> register requires a five-position rotate-through-carry.  The 20-bit
>>> enhancement to the ISA was really intended only to support a larger
>>> address space; to simplify validation of the machine description I've
>>> chosen to allow it to be used for any integer operation, but I have no
>>> reason to think that'll be common.
>> Ok. So these are pointer modes, essentially? For the target I'm working
>> on, I'm using the following patch, see if that helps you any. It seems
>> to apply to trunk, so I might as well ask for an OK if it bootstraps and
>> tests ok (but it has little use while these ports remain out-of-tree).
> Not that I can approve this anyway, but: what are the properties of

MODE_POINTER is intended to avoid problems where you have modes that
cannot be used as integer modes (because the arithmetic operations
doesn't exist on the machine), and which have odd conversions. It's a
way of keeping them out of the way of int_mode_for_size. I'm also
thinking of overloading the meaning so that MODE_POINTER occupies
exactly one register, even if it is bigger than BITS_PER_WORD (yes, ugh).

> It seems odd on the face of it for POINTER_MODE_P (Pmode) to be false
> on the majority of targets.  But that's probably just a naming thing.

On the majority of targets the distinction is meaningless since pointers
don't behave any differently than integers.


Reply via email to