Re: unable to find precise mode to match cpu word-bitsize 24

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Doug Evans wrote:

> This is new ground so we can decide how we want things to look, and then
> make it work.

  Well, what I'd particularly like in this case would be for my pc to
increment by one for each 24-bit insn, rather than have the model pretend to
be an 8-bit CISC machine processing all 3-byte instructions, if you see what I
mean.

> I think(!) that we don't want to redefine QI.

  Well, if you do a GCC port with #define BITS_PER_UNIT 24, don't you get a
24-bit QImode?  I don't know how closely the XXmodes in cgen are meant to
match the semantics of GCC's modes, or whether it's just a friendly and
familiar naming scheme to adopt.

> For clarity's sake, the T in TQI is for "Three", right?  [3 * 8 = 24]

  Yep.  I guess I could also call it PSImode by analogy to GCC.

> I've been thinking that while QI,HI,SI,DI are clear, any other similarly
> named modes might become problematic over time.
> 
> An alternative is I24 of course, but if one goes that route one needs to
> resolve what to do about QI,etc.
> [They *could* become aliases of I8, etc. and perhaps eventually be
> removed entirely, at least from the application independent core. 
> Anything related to gcc may certainly want to use them.]  This route has
> the benefit of solving this problem for future weird architectures. 
> [And just because we add I24 doesn't mean we'd have to immediately add
> all the others, e.g. I23, etc.]

  Well, the most flexible option I think would be to implement the equivalent
of BITS_PER_UNIT and have the QI/HI/SI/DI modes adjust to match, maybe.  I'm
really new to this and don't fully understand how modes are used in cgen yet,
but if it's ever a long-term goal to be able to cgen parts of the GCC backend,
it would be handy to mirror the same storage-layout abilities.

> Also, since it's related, I've been thinking of removing UQI, UHI, etc. 
> They were a useful internal implementation detail at one point, but I
> think they've become more of a problem than a help.

  Ah, I was wondering; GCC doesn't bother to represent signedness in the mode
definitions, it's explicit in RTL sign/zero extend operations.

    cheers,
      DaveK