From: Dave Korn <dave.korn.cygwin@googlemail.com>
To: Doug Evans <dje@sebabeach.org>
Cc: Dave Korn <dave.korn.cygwin@googlemail.com>, cgen@sources.redhat.com
Subject: Re: unable to find precise mode to match cpu word-bitsize 24
Date: Mon, 22 Jun 2009 00:05:00 -0000 [thread overview]
Message-ID: <4A3ECDBB.1000806@gmail.com> (raw)
In-Reply-To: <4A3EBD0E.5080109@sebabeach.org>
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
next prev parent reply other threads:[~2009-06-22 0:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-21 19:02 Dave Korn
2009-06-21 23:07 ` Doug Evans
2009-06-22 0:05 ` Dave Korn [this message]
2009-06-22 17:05 ` Doug Evans
2009-07-04 23:35 ` Dave Korn
2009-07-14 5:59 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A3ECDBB.1000806@gmail.com \
--to=dave.korn.cygwin@googlemail.com \
--cc=cgen@sources.redhat.com \
--cc=dje@sebabeach.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).