Browsing the GCC source, I found this in gcc/config/avr/avr.c
if (AVR_HAVE_RAMPZ
&& TEST_HARD_REG_BIT (set, REG_Z)
&& TEST_HARD_REG_BIT (set, REG_Z + 1))
{
emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD,
treg);
}
I wont pretend to full
Ah, this becomes (somewhat) clearer now. And then not...
Following it through, it seems that its possible to generate two
slightly differing prologues;
ignoring other registers, and assuming a tmp reg (r0), you get:
move treg, rampd
push treg
move rampd, 0
...
move treg, rampz
push treg
if AVR_
Ian,
Trying again... :-)
No, the "last one" should NOT be AVR_HAVE_RAMPZ.
The Z register and the RAMPD register are used together to address
memory in an AVR part which supports RAMPD.
Some later AVR micrcontrollers have a "Z" register (i.e., AVR_HAVE_RAMPZ
is set). Newer, more capable ver
Ok, I don't want to sound rude, but did anyone actually *read* what I wrote?
I'll highlight the parts of lines in question this time, perhaps that
will help...
if (AVR_HAVE_RAMPZ
^^
&& TEST_HARD_REG_BIT (set, REG_Z)
&& TEST_HARD_REG_BIT (set, REG_Z + 1))
Ian,
I apologize if I was being obtuse! :-)
The AVR_HAVE_RAMPD #define tells the routine "emit_push_sfr()" to save
the RAMPD register, but only if the third parameter to the call is
non-zero. The constant AVR_HAVE_RAMPD will be non-zero if the AVR
micro-architecture supports a RAMPD register
Maybe one day even a problem in 32bit architectures.
On Thu, Dec 16, 2021 at 7:50 PM Bruce D. Lightner
wrote:
> Ian,
>
> Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD
> #define indicates that the AVR chip in question supports the "RAMP" paging
> register, described as fol
Ian,
Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD
#define indicates that the AVR chip in question supports the "RAMP"
paging register, described as follows:
*RAMPD*
Register concatenated with the Z-register enabling direct addressing
of the whole data space on MCU
Browsing the GCC source, I found this in gcc/config/avr/avr.c
if (AVR_HAVE_RAMPZ
&& TEST_HARD_REG_BIT (set, REG_Z)
&& TEST_HARD_REG_BIT (set, REG_Z + 1))
{
emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD,
treg);
}
I wont pretend to fully
Anatoly and others.
Well the next bug on list of testsuite execute/torture failures for AVR
is for gcc's builtin_return_address.
This function is rarely used. But instead of ignoring it, it would be
better to fix it, that change test to exclude AVR.
Target is supposed to tell gcc the RTL ad
Hi All,
For those who are interested, I filed GCC bug #34932:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932>
Which is from WinAVR bug #1860717:
<https://sourceforge.net/tracker/index.php?func=detail&aid=1860717&group
_id=68108&atid=520074>
This is also now listed
Hi All,
I've gone through the GCC bug list for the AVR here:
<http://www.nongnu.org/avr-libc/bugs.html>
Looking for the bugs that need the most attention.
Here is what I've found that should have the top priority (in no particular
order):
19636 - ice-on-valid-code, fails on 4.
Stephan Eisvogel wrote:
Greetings,
Bug 18251 as discussed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
is afaict not fully resolved in gcc HEAD as of today. It compiles on
3.4.3 with no problems so this appears to be a 4.x regression.
I have not filed a bug report with gcc bugzilla as
Greetings,
Bug 18251 as discussed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
is afaict not fully resolved in gcc HEAD as of today. It compiles on
3.4.3 with no problems so this appears to be a 4.x regression.
I have not filed a bug report with gcc bugzilla as I have never done
is destroyed . this will make gcc change code and sometimes it works!
Andy Hutchinson
-Original Message-From: Stephan Eisvogel <[EMAIL PROTECTED]>To: avr-gcc-list@nongnu.orgSent: Fri, 22 Apr 2005 17:17:03 +0200Subject: [avr-gcc-list] avr-gcc bug 18251 not resolved (ice-on-valid-
14 matches
Mail list logo
