From: Richard Earnshaw <rearnsha@arm.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: richard.earnshaw@arm.com
Subject: Re: support for ARM GNU/Linux
Date: Wed, 14 Apr 1999 12:18:00 -0000 [thread overview]
Message-ID: <199904141917.UAA27757@sun52.NIS.cambridge> (raw)
In-Reply-To: <199904141834.LAA12554@andros.cygnus.com>
shebs@cygnus.com said:
> A side-note, before ARM Architecture v4 many "undefined"
> instruction formats aren't guaranteed to take the undefined
> instruction trap. Also note that, in this respect, the ARM7TDMI
> is NOT fully ARM v4 compliant.
> I don't quite understand - I hope ARM7TDMI is guaranteed to take the
> trap, since Angel monitors are depending on that.
I should have been more precise with my wording. The words in the ARM ARM
say
that ARMv4 defines several new undefined instructions (ie instructions
that will take the undefined instruction trap). In fact, although the
7TDMI is nominally v4t (and hence includes all of v4) it does not in fact
add the new undefined instructions, though it implements the rest of the
v4 architecture. The new undefined instructions in v4 are all
instructions which had no defined behaviour in earlier chips (but for
which there was no guarantee that they would raise an exception); I
believe most of the instructions were NOPs but I could be wrong.
In practice, I think it is only safe to rely on instructions matching
3 2 2 2 2 2
1 8 7 6 5 4 5 4 3 0
C C C C 0 1 1 x x x x x x x x x x x x x x x x x x x x 1 x x x x
taking the undefined trap, and even then only when the condition predicate
is true.
> I don't know if anyone cares about RISC iX support any more (though
> gcc still supports it).
> You'd be most likely to know if anyone would, methinks! Since we've
> adopted a policy of marking and ultimately deleting obsolete code in
> GDB, and RISC iX is one of the candidates, any information you could
> provide would be helpful. Do you know if anybody is using a RISC iX
> system nowadays, and if they would have any interest in a port of
> current GDB?
Not necessarily, it was an Acorn Product not an ARM one. I do have one at
home, but it's slow by today's standards and makes a lot of noise, so it
isn't switched on very often (I really only keep it in case a problem gets
reported).
next prev parent reply other threads:[~1999-04-14 12:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-12 12:26 Philip Blundell
1999-04-12 13:19 ` Scott Bambrough
1999-04-12 14:12 ` Scott Bambrough
1999-04-12 14:27 ` Philip Blundell
1999-04-12 20:18 ` Jim Blandy
1999-04-13 6:45 ` Philip Blundell
[not found] ` <E10X3Uv-0003Kd-00.cygnus.patches.gdb@fountain.nexus.co.uk>
1999-04-13 22:44 ` Andrew Cagney
1999-04-14 2:21 ` Philip Blundell
1999-04-14 3:36 ` Richard Earnshaw
1999-04-14 2:52 ` Richard Earnshaw
1999-04-14 11:34 ` Stan Shebs
1999-04-14 12:18 ` Richard Earnshaw [this message]
[not found] ` <37142B16.B43B5200.cygnus.patches.gdb@cygnus.com>
1999-04-13 23:56 ` Andrew Cagney
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=199904141917.UAA27757@sun52.NIS.cambridge \
--to=rearnsha@arm.com \
--cc=richard.earnshaw@arm.com \
--cc=shebs@cygnus.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