public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Geoff Keating <geoffk@geoffk.org>
To: dje@transmeta.com (Doug Evans)
Cc: cgen@sources.redhat.com
Subject: Re: field-start and varying word sizes
Date: Tue, 03 Jul 2001 15:32:00 -0000	[thread overview]
Message-ID: <jmzoalk4tt.fsf@geoffk.org> (raw)
In-Reply-To: <15170.15391.989073.581389.cygnus.local.cgen@casey.transmeta.com>

dje@transmeta.com (Doug Evans) writes:

> Geoff Keating writes:
>  > Despite the comment, m32r has 
>  >   (insn-lsb0? #f)
>  > and so all this code comes down to the trivial case anyway.
> 
> The comment was directed towards the kind of chip the m32r is.
> You're taking the comment too literally.
> 
>  > OK to commit?
> 
> I'm not convinced. [not saying I can't be, just that I'm not there yet]
> 
> What should be returned in the following case? [for example]
> 
> lsb0? #f
> wanted-word-len 32
> recorded-word-len 16
> endian little

An interesting question.  The current code, and the code with my patch,
both return

(bitrange-start bitrange)

but in this case, I believe that the correct thing is to return

(+ (bitrange-start bitrange) (- wanted-word-len
                                recorded-word-len))

and so this code doesn't currently work for this case, and still
doesn't work with my patch.

An interesting question is whether this can ever happen.  It would
imply that you have a port with little-endian instructions, and
variable-length instructions, but you're numbering your bits starting
from the end of the instruction; so you might have

(dnf f-f1 "some byte" () 0 8)

which refers to byte 1 for 16-bit-long instructions, but to 
byte 3 for for 32-bit-long instructions.

Now, it's not that this doesn't make sense; you would have

(dnf f-op1-16 "first byte for short insns" () 8 8)
(dnf f-op1-32 "first byte for long insns" () 24 8)
(dnf f-op2-32 "middle word for long insns" () 8 16)

and then perhaps

(dni short
  "A short instruction"
  ()
  ("short")
  (+ (f-op1-16 #x01) (f-f1 #x00))
  ()
  ()
)
(dni long
  "A longer instruction"
  ()
  ("long")
  (+ (f-op1-32 #x02) (f-op2-32 #x1234) (f-f1 #x56))
  ()
  ()
)

and these would describe the instructions with bytes
01 00
and
02 34 12 56
respectively.  I don't think it would be a good idea to write a .cpu
file like this, though.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

  parent reply	other threads:[~2001-07-03 15:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-03 13:39 Geoff Keating
2001-07-03 14:42 ` Doug Evans
     [not found] ` <15170.15391.989073.581389.cygnus.local.cgen@casey.transmeta.com>
2001-07-03 15:32   ` Geoff Keating [this message]
     [not found] <200107032054.NAA01495.cygnus.local.cgen@geoffk.org>
2001-07-03 14:24 ` Frank Ch. Eigler
     [not found] ` <o5wv5pzoy1.fsf.cygnus.local.cgen@toenail.toronto.redhat.com>
2001-07-03 15:12   ` Geoff Keating

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=jmzoalk4tt.fsf@geoffk.org \
    --to=geoffk@geoffk.org \
    --cc=cgen@sources.redhat.com \
    --cc=dje@transmeta.com \
    /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).