Re: CC0 to CCmode conversion

[Björn Haase]

Hi Denis,

I have had a look at your patch. It generally seems to work. Presently it 
still misses some optimization where the old cc0 back-end was smarter. The 
testsuite also reports a couple of new failures.

Yours,

Björn.

Here are a couple of cases where the old cc0 interface generated better code:

--- ./cc0/test.s2005-03-09 21:45:49.0 +0100
+++ ./CC/test.s 2005-03-18 22:40:20.0 +0100
@@ -96,19 +96,21 @@

-   cpi r17,lo8(31)
+   cpi r17,lo8(30)
+   breq .+2
brsh .L14


-   cpi r17,lo8(30)
+   cpi r17,lo8(29)
+   breq .L18
brlo .L18


@@ -405,7 +415,7 @@
 /* prologue end (size=0) */
call Hardware_SetRedLED
lds r18,g_ucBuzzerOff
-   tst r18
+   cpi r18,lo8(0)
brne .L82
ldi r24,lo8(1000)
ldi r25,hi8(1000)


ldi r17,hi8(25)
rjmp .L151
 .L147:
-   cp __zero_reg__,r22
-   cpc __zero_reg__,r23
-   brlt .L151
+   cp r22,__zero_reg__
+   cpc r23,__zero_reg__
+   breq .+2
+   brpl .L151



Results from the testsuite run:

Tests that now fail, but worked before:

gcc.c-torture/compile/20031220-2.c  -O1  (test for excess errors)
gcc.c-torture/compile/20031220-2.c  -O2  (test for excess errors)
gcc.c-torture/compile/20031220-2.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
gcc.c-torture/compile/20031220-2.c  -O3 -fomit-frame-pointer -funroll-loops
(test for excess errors)
gcc.c-torture/compile/20031220-2.c  -O3 -fomit-frame-pointer  (test for
 excess errors)
gcc.c-torture/compile/20031220-2.c  -O3 -g  (test for excess errors)
gcc.c-torture/compile/20031220-2.c  -Os  (test for excess errors)
gcc.c-torture/execute/20030606-1.c execution,  -O1
gcc.c-torture/execute/20030606-1.c execution,  -O2
gcc.c-torture/execute/20030606-1.c execution,  -O3 -fomit-frame-pointer
gcc.c-torture/execute/20030606-1.c execution,  -O3 -g
gcc.c-torture/execute/20030606-1.c execution,  -Os
gcc.c-torture/execute/931004-6.c execution,  -Os
gcc.c-torture/execute/builtins/memcmp.c execution,  -O1
gcc.c-torture/execute/builtins/memcmp.c execution,  -O2
gcc.c-torture/execute/builtins/memcmp.c execution,  -O3 -fomit-frame-pointer
gcc.c-torture/execute/builtins/memcmp.c execution,  -O3 -g
gcc.c-torture/execute/builtins/memcmp.c execution,  -Os
gcc.c-torture/execute/compare-1.c execution,  -O1
gcc.c-torture/execute/compare-1.c execution,  -O2
gcc.c-torture/execute/compare-1.c execution,  -Os
gcc.c-torture/execute/divcmp-1.c execution,  -O1
gcc.c-torture/execute/divcmp-1.c execution,  -O2
gcc.c-torture/execute/divcmp-4.c execution,  -O1
gcc.c-torture/execute/divcmp-4.c execution,  -O2
gcc.c-torture/execute/int-compare.c execution,  -O1
gcc.c-torture/execute/int-compare.c execution,  -O2

New tests that FAIL:

gcc.dg/tree-ssa/ssa-ccp-3.c scan-tree-dump-times link_error 0

New tests that PASS:

gcc.dg/tree-ssa/20030731-2.c scan-tree-dump-times if  1
gcc.dg/tree-ssa/20030917-1.c scan-tree-dump-times foo .defval 1
gcc.dg/tree-ssa/20030917-3.c scan-tree-dump-times printf.*, 0 1
gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times if  2
gcc.dg/tree-ssa/20031015-1.c scan-tree-dump-times V_MAY_DEF 2
gcc.dg/tree-ssa/20031022-1.c scan-tree-dump-times entry_exit_blocks.1..pred 1
gcc.dg/tree-ssa/20040210-1.c scan-tree-dump-times if  2
gcc.dg/tree-ssa/20040216-1.c scan-tree-dump-times Deleted dead store 2
gcc.dg/tree-ssa/20040305-1.c scan-tree-dump-times if  2
gcc.dg/tree-ssa/20040305-1.c scan-tree-dump-times Replaced 1
gcc.dg/tree-ssa/20040513-1.c scan-tree-dump-times \(_Bool\) 0
gcc.dg/tree-ssa/20040513-2.c scan-tree-dump-times link_error 0
gcc.dg/tree-ssa/20040514-1.c scan-tree-dump-times if  0
gcc.dg/tree-ssa/20040518-1.c scan-tree-dump-times if  0
gcc.dg/tree-ssa/20040518-2.c scan-tree-dump-times ABS_EXPR 1
gcc.dg/tree-ssa/20040518-2.c scan-tree-dump-times straightline 1
gcc.dg/tree-ssa/20040615-1.c scan-tree-dump-times bar2 0
gcc.dg/tree-ssa/20040624-1.c scan-tree-dump-times if  1
gcc.dg/tree-ssa/20040703-1.c scan-tree-dump-times 0\.0 0
gcc.dg/tree-ssa/20040721-1.c scan-tree-dump-times = G; 0
gcc.dg/tree-ssa/20040729-1.c scan-tree-dump-times &x 0
gcc.dg/tree-ssa/20040911-1.c scan-tree-dump-not VUSE 

Re: Question about "#pragma pack(n)" and "-fpack-struct"

[Thorsten Glaser]

James E Wilson dixit:

>Currently, -fpack-struct is defined
>to have the same effect as attribute ((packed)) for all structures,
>which in turn is equivalent to #pragma pack(1) for all structures.

Let me please add a feature request here.

gcc warns if it cannot pack structs since they're already
in a more or less optimal form.

When you're using headers for structures e.g. used for PXE,
you've got to pack them since the data comes from the BIOS.

Using __attribute__((packed)) on these structures will then
give you a warning on i386 (and maybe none on amd64, but I
have not checked that).

When you're building with -Werror, that plainly sucks.

Luckily, my gcc 3.4.4 seems to not warn if I use #pragma pack;
that's all I request to be retained.

bye,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.  (aus d.a.s.r)

Re: __builtin_cpow((0,0),(0,0))

[Vincent Lefevre]

On 2005-03-13 15:26:05 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | When one uses the power notation in mathematics, one (almost) never
> | says when the context is a function R x R -> R or R x Z -> R or
> | whatever.
> 
> That is (almost) absolutely false.

Yourself didn't mention the context.

> | The problem is the same in ISO C99 (and probably other languages),
> 
> Other languages do make the distinction.  That C99 did not have the
> syntax for that is a defect rather than virtue. Examples have been
> provided, but I guess you prefer to ignore them.

But the point is that C99 doesn't make the different. So, gcc should
make sure that in C, cpow((0,0),(0,0)) is equal to 1, to be able to
use cpow as an integer power function.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: gcc 3.4.3 bug C++/inlines/thumb

[Paul Brook]

On Saturday 19 March 2005 07:51, Carl van_Schaik wrote:
> I'm running into a bug with gcc 3.4.3:
>
> I've got syscall code for user-land to our kernel that trashes r14/lr.
> The code is inlined, and works find in ARM mode. When compiling in thumb,
> gcc does not preserve lr. With an older gcc 3.3.3, the code was not
> inlined, but generated correctly.

This has been fixed in later versions by this patch:

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01739.html

Paul

Build and test results: gcc-3.4.3 on Red Hat 8.0

[Anna Aret]

Hi,

Here are build and test results for gcc-3.4.3 on standard (just slightly
upgraded) Red Hat Linux 8.0 system. Everything worked fine.

Regards,
Anna Aret
==
config.guess
i686-pc-linux-gnu

gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --enable-languages=f77
Thread model: posix
gcc version 3.4.3

/etc/issue
Red Hat Linux release 8.0 (Psyche)

uname -a
Linux sirius 2.4.20-28.8 #1 Thu Dec 18 12:25:00 EST 2003 i686 athlon i386 
GNU/Linux

rpm -q glibc
glibc-2.3.2-4.80.8
==

LAST_UPDATED: Obtained from CVS: -rgcc_3_4_3_release 

Native configuration is i686-pc-linux-gnu

=== g77 tests ===


Running target unix

=== g77 Summary ===

# of expected passes1824
/home/software/gcc-3.4.3-objdir/gcc/testsuite/../g77 version 3.4.3

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/execute/va-arg-25.c execution,  -Os 

=== gcc Summary ===

# of expected passes24877
# of unexpected failures1
# of expected failures  69
# of untested testcases 7
# of unsupported tests  199
/home/software/gcc-3.4.3-objdir/gcc/xgcc version 3.4.3


Compiler version: 3.4.3 
Platform: i686-pc-linux-gnu
configure flags: --enable-languages=f77

Re: AVR: CC0 to CCmode conversion

[Denis Chertykov]

Paul Schlie <[EMAIL PROTECTED]> writes:

> > From: Denis Chertykov <[EMAIL PROTECTED]>
> >> Paul Schlie <[EMAIL PROTECTED]> writes:
> >>> Denis wrote:
> >>> I have converted the AVR port from CC0 to CCmode.
> >>> But may be I have converted the port in wrong way.
> >>> (It's because I was interested in *this* way.)
> >>> 
> >>> I have used CCmode register and havn't added the
> >>> '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
> >>> CC_REGNUM just because AVR is'n needed in scheduling.
> >>> I think that sequence of compare + cond-jump will exists in any
> >>> compiler pass.
> >>> The port was successfully tested without new regressions.
> >>> What do you (MAINTAINERS) think about this ?
> >> 
> >> Interesting:
> >> 
> >> - might you be able to post the resulting port files for review?
> > 
> > patch against cvs:
> > http://home.overta.ru/users/denisc/cc0-ccmode/cc0-ccmode.patch.gz
> > new port:
> > http://home.overta.ru/users/denisc/cc0-ccmode/avr.tgz
> 
> - Thank you, I've had the chance to review it to better understand.
> 
> >> - are you proposing that all conditional branches then required to be
> >>   explicitly paired with a corresponding immediately previous compare
> >>   instruction?
> > 
> > I founded that GCC isn't break cmp+jump sequences.
> > (My port havn't scheduling.)
> 
> - Maybe presently, but there's nothing in the machine description which
>   would seem to prohibit it either. (continued in following section)

As I know only scheduler can break cmp+jump.
AVR need not in any scheduling.

> >>   (if so, how is this a good thing observing that it's fairly typical
> >>   for most conditional branches to be naturally based on comparisons
> >>   against 0 resulting from the immediately preceding operation, which
> >>   would have otherwise not required an explicit compare?)
> > 
> > I think that it's not good.
> 
> - although I agree that there's likely a cleaner more consistent way to
>   accurately describe and track condition-code side-effects of AVR's ISA,
>   it seems that this approach actually inhibits GCC helping to optimize
>   the code, as too much information is being hidden from it?

I don't want to hide useful information. I want to ignore unusable.

For example: even i386 port (probably better port) isn't
"accurately describe and track condition-code side-effects"

Look at *addsi_1:

(define_insn "*addsi_1"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=r,rm,r")
(plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0,0,r")
 (match_operand:SI 2 "general_operand" "rmni,rni,lni")))
   (clobber (reg:CC FLAGS_REG))]
  "ix86_binary_operator_ok (PLUS, SImode, operands)"

FLAGS_REG just clobbered. It's not a true.
As I understand '(clobber (reg:CC FLAGS_REG))' needed only for
scheduling.
AVR havn't scheduling and I want to omit such clobbers, but I have
added special insns for optimization.

For example:

(define_insn "*subqi_3"
  [(set (reg CC_REGNUM)
(compare (match_operand:QI 1 "register_operand" "0,0")
 (match_operand:QI 2 "nonmemory_operand" "r,i")))
   (set (match_operand:QI 0 "nonimmediate_operand" "=r,d")
(minus:QI (match_dup 1) (match_dup 2)))]
  "avr_match_ccmode (insn, CC_ZNmode)"



>   For example:
> 
>   It seems that by relying on peephole optimization to try to eliminate
>   otherwise redundant explicit expensive comparison operations on wider
>   than byte sized operands which were generated because multi-byte wide
>   operations don't expose their cc-mode side-effects, may not be a good
>   strategy?

I'm agree that may be better to split HImode comparision to
two QImode comparisions, but it's a next step. For this step you not
needed to change something outside HImode comparision.

> 
>   As it would seem that the initial hiding of this critical information
>   only inhibits GCC from being able to optimally (not to mention safely)
>   schedule basic block instruction sequences in an effort to eliminate
>   the necessity of otherwise relatively expensive multi-byte comparisons
>   to begin with. (Which would seem to be more optimal than relying on
>   no scheduling, and likely only catching some of the potential
>   opportunities to eliminate expensive compares after the fact?)

Ohhh. I'm probably understand you. Are you mean that better way for
splitting comparisions is
cmpHI, cbranch  ->  cmpQI1_and_set_CC, cbranch1, cmpQI2_and_use_CC, cbranch2 ?
In this case cmpQI1,cbranch1 may be in one basic block
and cmpQI2, cbranch2 in another. You right it's impossible without
"accurately describe and track condition-code side-effects".
If you (or any other) want to support such splitting then clobbers
must be added to insns.

I think that better to support
cmpHI, cbranch  ->  cmpQI1_set_CC, cmpQI2_use_CC, cbranch.
because AVR is a microcontroller and code size more important than code speed.

Denis.

Re: CC0 to CCmode conversion

[Denis Chertykov]

Bernardo Innocenti <[EMAIL PROTECTED]> writes:

> Denis Chertykov wrote:
> 
> > I have converted the AVR port from CC0 to CCmode.
> 
> That's indeed very good news.  Incidentally, CC0
> conversion of the AVR target was being discussed
> in an off-list thread with Andy Hutchinson.
> 
> 
> > But may be I have converted the port in wrong way.
> > (It's because I was interested in *this* way.)
> 
> Uh?  That's very bad news.
> 
> 
> > I have used CCmode register and havn't added the
> > '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
> > CC_REGNUM just because AVR is'n needed in scheduling.
> > I think that sequence of compare + cond-jump will exists in any
> > compiler pass.
> > The port was successfully tested without new regressions.
> 
> Did you notice any pessimization spots in the generated
> code?  IIRC, the converted H8 backend required some
> massaging before it was back on par with the old
> version.

I have a bit pessimization but compare/branch operations can be
optimized even more than CC0 version.

Denis.

Copyright question: libgcc GPL exceptions

[Bernd Schmidt]

I'm updating the copyrights in the Blackfin port, and I noticed that 
there appear to be two versions of the wording that allows more-or-less 
unlimited use of libgcc files.  One can be found e.g. in 
config/arm/crtn.asm:

  As a special exception, if you link this library with files
  compiled with GCC to produce an executable, this does not cause
  the resulting executable to be covered by the GNU General Public
  License.
  This exception does not however invalidate any other reasons why
  the executable file might be covered by the GNU General Public
  License.
the other in config/arm/lib1funcs.asm:
  In addition to the permissions in the GNU General Public License, the
  Free Software Foundation gives you unlimited permission to link the
  compiled version of this file into combinations with other programs,
  and to distribute those combinations without any restriction coming
  from the use of this file.  (The General Public License restrictions
  do apply in other respects; for example, they cover modification of
  the file, and distribution when not linked into a combine
  executable.)
Is there a particular reason to use one or the other, or are they 
equivalent?

Bernd

AVR indirect_jump addresses limited to 16 bits

[Marek Michalkiewicz]

Hello,

I'm looking into adding support for ATmega256x and larger devices to
the AVR port.  This means that program memory addresses no longer fit
in 16 bits - and I'm looking how to avoid making pointers larger.

Jumps and function calls are no problem as long as they use labels
(constant addresses).  Indirect jumps and calls (address in a register)
are a problem.  For function calls, it seems easy - generate each
function in two parts, placed by linker script in different sections:

 - jump to function body
 - function body

and locate the jumps below 128K (64K words), while the function body
can be anywhere in the address space.  If you need to take a 16-bit
address of the function, simply take the address of the jump.  The
added runtime overhead of the jump is a small price to pay compared
to making pointers 3 or 4 bytes long (instead of 2 bytes) on the AVR.

But, now there is the "indirect_jump" pattern - mandatory, even though
I haven't yet seen it actually used in real applications on the AVR.
The question is, how to make sure that if indirect_jump ever happens
to be used, its target address is guaranteed to fit in 16 bits?  Where
do these pointers come from?  (Like function pointers come from taking
the address of a function, and this may be solved as described above.)

Looking at the source, I've found one use of indirect_jump so far -
returning from a function with some data still on the stack.
I suspect this may not work properly on the AVR anyway, because
return address is stored on the stack in the wrong byte order -
big endian, even though the AVR is little endian.  Anything else?

Thanks,
Marek

Re: AVR: CC0 to CCmode conversion

[Paul Schlie]

> From: Denis Chertykov <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>>> From: Denis Chertykov <[EMAIL PROTECTED]>
>> - although I agree that there's likely a cleaner more consistent way
>>   to accurately describe and track condition-code side-effects of AVR's
>>   ISA, it seems that this approach actually inhibits GCC helping to
>>   optimize the code, as too much information is being hidden from it?
> 
> I don't want to hide useful information. I want to ignore unusable.
> 
> For example: even i386 port (probably better port) isn't
> "accurately describe and track condition-code side-effects"
> 
> FLAGS_REG just clobbered. It's not a true.
> As I understand '(clobber (reg:CC FLAGS_REG))' needed only for
> scheduling.
> AVR havn't scheduling and I want to omit such clobbers, but I have
> added special insns for optimization.
> For example: ...

- yes but only for QI mode operations, but not otherwise; which prohibits
  safe instruction re-ordering/scheduling, which I understand you rely on
  not occurring, then use peephole optimization in an effort to identify
  opportunities to eliminate otherwise redundant compare operations.

- alternatively, why not accurately expose the instruction's FLAGS_REG
  side-effects, and enable GCC to re-order/schedule (maintaining the fully
  exposed data-flow-control-graph's sequential dependencies) to attempt
  to find more optimal sequences which may reduce the cost of an arbitrary
  instruction sequence within a basic block (including the potential
  elimination of explicit comparison operations, when an instruction which
  generates the necessary FLAGS_REG side-effect may be safely re-ordered
  prior to it's requirement with no instructions with interfering
  side-effects in between)?

>> ...
>>   As it would seem that the initial hiding of this critical information
>>   only inhibits GCC from being able to optimally (not to mention safely)
>>   schedule basic block instruction sequences in an effort to eliminate
>>   the necessity of otherwise relatively expensive multi-byte comparisons
>>   to begin with. (Which would seem to be more optimal than relying on
>>   no scheduling, and likely only catching some of the potential
>>   opportunities to eliminate expensive compares after the fact?)
> 
> Ohhh. I'm probably understand you. Are you mean that better way for
> splitting comparisions is cmpHI,
> cbranch -> cmpQI1_and_set_CC, cbranch1, cmpQI2_and_use_CC, cbranch2 ?
> In this case cmpQI1,cbranch1 may be in one basic block
> and cmpQI2, cbranch2 in another. You right it's impossible without
> "accurately describe and track condition-code side-effects".
> If you (or any other) want to support such splitting then clobbers
> must be added to insns.

- basically yes, but it would seem that it's necessary to accurately
  describe instructions side effects to do so optimally; as clobbering
  FLAGS_REG only prevents unsafe re-reordering, it doesn't enable optimal
  reordering (which would seem to be one of the few optimizations that GCC
  could do for avr, or other lightly pipelined in-order issue/completion
  targets, and would be unfortunate to prohibit)?

> I think that better to support
> cmpHI, cbranch  ->  cmpQI1_set_CC, cmpQI2_use_CC, cbranch. because
> AVR is a microcontroller and code size more important than code speed.

- I fully agree that code-size tends to be most important, which is why I
  believe it's important to enable instruction scheduling/re-ordering
  optimizations that are capable of eliminating potentially unnecessary
  explicit comparison operations for wider than byte-sized operand results
  against 0, if the instructions within a basic block can be safely
  rescheduled to eliminate them.

  Which would seem to require that both instruction FLAGS_REG side-effects
  be fully exposed, and correspondingly that conditional branches expose
  their dependency on them (and all are visible during DFCG scheduling).

- possibly something like: ?

  (define_insn "*addhi3"
[(set (match_operand:HI 0 ...)
   (plus:HI (match_operand:HI 1 ...)
(match_operand:HI 2 ...)))
 (set (reg ZCMP_FLAGS)
   (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))
 (set (reg CARRY_FLAGS)
   (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))]
""
"@ add %A0,%A2\;adc %B0,%B2
   ..."
[(set_attr "length" "2, ...")])

  (define_insn "*andhi3"
[(set (match_operand:HI 0 ...)
   (and:HI (match_operand:HI 1 ...)
   (match_operand:HI 2 ...)))
 (set (reg ZCMP_FLAGS)
   (compare:HI (and:HI (match_dup 1) (match_dup 2))) (const_int 0))]
""
"@ and %A0,%A2\;and %B0,%B2
   ..."
[(set_attr "length" "2, ...")])

  (define_insn "*comparehi"
[(set (reg ZCMP_FLAGS)
   (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))
 (set (reg CARRY_FLAGS)
   (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))]
""
"@

Re: AVR: CC0 to CCmode conversion

[Paul Schlie]

Sorry meant denote the setting of FLAG_REGS based solely on it's result,
which should be implied by operand 0, the target of 3-operand instructions;
with the exception of compare, as it's effective target are the FLAGS_REGS.

corrected below:

> From: Paul Schlie <[EMAIL PROTECTED]>
> - possibly something like: ?

  (define_insn "*minushi3"
[(set (match_operand:HI 0 ...)
   (minus:HI (match_operand:HI 1 ...)
 (match_operand:HI 2 ...)))
 (set (reg ZCMP_FLAGS)
   (compare:HI (match_dup 0) (const_int 0)))
 (set (reg CARRY_FLAGS)
   (compare:HI (match_dup 0) (const_int 0)))]
""
"@ add %A0,%A2\;adc %B0,%B2
   ..."
[(set_attr "length" "2, ...")])

  (define_insn "*andhi3"
[(set (match_operand:HI 0 ...)
   (and:HI (match_operand:HI 1 ...)
   (match_operand:HI 2 ...)))
 (set (reg ZCMP_FLAGS)
   (compare:HI (match_dup 0) (const_int 0)))]
""
"@ and %A0,%A2\;and %B0,%B2
   ..."
[(set_attr "length" "2, ...")])

  (define_insn "*comparehi"
[(set (reg ZCMP_FLAGS)
   (compare:HI (minus:HI (match_operand:HI 1 ...)
 (match_operand:HI 2 ...))
   (const_int 0)))
 (set (reg CARRY_FLAGS)
   (compare:HI (minus:HI (match_operand:HI 1 ...)
 (match_operand:HI 2 ...))
   (const_int 0)))]
""
"@ cp %A0,%A0\;cpc %B0,%B1
   ..."
[(set_attr "length" "2, ...")])

  (define_insn "branch"
[(set (pc)
   (if_then_else (condition (reg ZCMP_FLAGS) (match_operand 1 ...))
 (label_ref (match_operand 0 ...))
 (pc)))]
"* return ret_cond_branch (operands);
   ..."
[(set_attr "type" "branch")])

Re: AVR: CC0 to CCmode conversion

[Björn Haase]

Hi Paul,

I have the impression that you are trying to open open doors :-) : If IIUC 
what Denis aims to do is to segment the re-organization of the back-end into 
several independent small steps. One step will be the cc0 -> CC_mode issue he 
is addressing now. The splitting issue would be one of the following steps. 
One will have to verify this point, but it seems that only the splitting 
issue requires accurate tracking of all the clobbers/settings of the 
condition code.

In my opinion segmenting the rework of the back-end would indeed be the best 
approach, also because I expect that the instruction patterns *with* 
splitting will be fairly different. E.g. I do not think that the "addsi3" 
will be present any more. So it would be probably a lot of useless work to 
add all of the clobbers for instruction patterns that are likely to vanish in 
the near future.

Yours,

Björn

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> Marek Michalkiewicz wrote:
> I'm looking into adding support for ATmega256x and larger devices to
> the AVR port.  This means that program memory addresses no longer fit
> in 16 bits - and I'm looking how to avoid making pointers larger.

- Fully agree, just can't keep from wondering if this may be most
  efficiency accomplish by simply requiring the alignment of all
  function entry points to be two instruction word aligned. Thereby
  although there will be some more inefficiency than otherwise required
  for code mapped @ <64K; apps with even as many as 1K or so functions
  (which is likely a lot for even large avr apps), it would only imply
  a worst-case inefficiency of 1K instruction words, but likely averaging
  closer to 500 words, which seems like a small price to pay for an
  additional 64K words of program space. (and would likely less than the
  corresponding overhead of having to thread function entries to their
  bodies otherwise).

  Thereby all function address pointers simply first set the extended
  code address register bit to the logical high order address bit of the
  16-bit code pointer. which technically is likely best physically mapped
  into the low-order bit of the function pointer so that it does not need
  to cleared prior to use (effectively implying that function entries <64K
  are aligned to even word addresses, and those >64K are aligned to odd word
  address.

  (no jump tables, etc, required)

  ???

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Paul Schlie <[EMAIL PROTECTED]>
>> Marek Michalkiewicz wrote:
>> I'm looking into adding support for ATmega256x and larger devices to
>> the AVR port.  This means that program memory addresses no longer fit
>> in 16 bits - and I'm looking how to avoid making pointers larger.
> 
> - Fully agree, just can't keep from wondering if this may be most
>   efficiency accomplish by simply requiring the alignment of all
>   function entry points to be two instruction word aligned. Thereby
>   although there will be some more inefficiency than otherwise required
>   for code mapped @ <64K; apps with even as many as 1K or so functions
>   (which is likely a lot for even large avr apps), it would only imply
>   a worst-case inefficiency of 1K instruction words, but likely averaging
>   closer to 500 words, which seems like a small price to pay for an
>   additional 64K words of program space. (and would likely less than the
>   corresponding overhead of having to thread function entries to their
>   bodies otherwise).
> 
>   Thereby all function address pointers simply first set the extended
>   code address register bit to the logical high order address bit of the
>   16-bit code pointer. which technically is likely best physically mapped
>   into the low-order bit of the function pointer so that it does not need
>   to cleared prior to use (effectively implying that function entries <64K
>   are aligned to even word addresses, and those >64K are aligned to odd word
>   address.
> 
>   (no jump tables, etc, required)

- and likely continue to assume that the static-const progmem mapped data
  simply remains limited to a maximum of 64K-bytes mapped into the lower 32K
  words of program memory space to keep it's addressing and access simple,
  uniform and efficient within the constraints of AVR's ISA. (which seems
  likely reasonable?)

converting Ada to handle USE_MAPPED_LOCATION

[Per Bothner]

I fixed the regressions USE_MAPPED_LOCATION for C and C++, and
we've now branched, so it's is probably time to get Ada working.
(There is a Java problem, for which I have a patch, but it may
hurt debugging.  Until that is fixed, leave Java out of
--enable-languages, or apply this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01094.html )
Some links to the pervious discussions:
http://gcc.gnu.org/ml/gcc/2004-10/msg00012.html
http://gcc.gnu.org/ml/gcc/2004-10/msg00200.html
http://gcc.gnu.org/ml/gcc/2004-10/msg00229.html
http://gcc.gnu.org/ml/gcc/2004-10/msg00248.html
http://gcc.gnu.org/ml/gcc/2004-10/msg00261.html
http://gcc.gnu.org/ml/gcc/2004-10/msg00265.html
There wasn't really a consensus on how to do it.  The ideal solution
I think is for Ada to use line-map's source_location for Sloc in its lexer.
I don't think it would be that hard, but an easier solution may be
to leave Sloc alone, and instead translate Sloc integers to source_location
when we translate the Ada intermal format to Gcc trees. See:
http://gcc.gnu.org/ml/gcc/2004-10/msg00248.html
I think this is my current recommendation; to expand on it a little:
We can add a new function line-map.h:
  source_location
  linemap_get_location (struct line_table*,
const char *filename, int line, int column);
A simple implementation:
(1) check that (file, line, column) can use the current line_map:
   strcmp (filename, map->to_file) == 0
   && line >= map->to_line
   && column < (1 << map->column_bits)
   && line not excessively big;
   The latter is a heuristic to avoid using up line number too greedily;
   I suspect it may not be an issue.
(2) If the test passes, calculate the source_location from (line, column)
  using map->start_location and map->column_bits.  Also update
highest_location and highest_line.
(3) Otherwise, allocate a new map using linemap_add.
In the future we can improve linemap_get_location if it turns out to be
necessarily; for example searching previously used map entries and/or
keeping a cache of recently used maps.
Some people suggested instead that the location_t in the shared Gcc
should be a language-defined opaque time, and have language call-backs.
The default would be source_location as managed by line_map, but Ada
could use a different implementation.  That may be a short-term easier
for Ada, but I don't think it's the best long-term solution for Gcc
as a whole.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: AVR: CC0 to CCmode conversion

[Paul Schlie]

> From: Björn Haase <[EMAIL PROTECTED]>
> I have the impression that you are trying to open open doors :-) : If IIUC
> what Denis aims to do is to segment the re-organization of the back-end into
> several independent small steps. One step will be the cc0 -> CC_mode issue he
> is addressing now. The splitting issue would be one of the following steps.
> One will have to verify this point, but it seems that only the splitting
> issue requires accurate tracking of all the clobbers/settings of the
> condition code.
> 
> In my opinion segmenting the rework of the back-end would indeed be the best
> approach, also because I expect that the instruction patterns *with*
> splitting will be fairly different. E.g. I do not think that the "addsi3"
> will be present any more. So it would be probably a lot of useless work to
> add all of the clobbers for instruction patterns that are likely to vanish in
> the near future.

Thank you, however I still don't understand the advantage of adopting an
intermediate step which only seems to prohibit all forms of scheduling; and
likely producing inferior code when multi-byte comparisons against 0 can't
be peephole optimized away because the operation which may have produced
equivalent side-effects doesn't happen to immediately sequentially precede
it?

Maybe I misunderstand the generality of the specified compare/if-then-else
peephole optimizations?  Are they guaranteed to match any opportunity to
eliminate otherwise redundant a multi-byte comparison against 0, by forcing
an exiting equivalent side-effect producing operation to be sequentially
safely placed immediately preceding it's requirement (thereby effectively
forcing an instruction ordering)?

If this is the case, then my concerns are mostly satisfied; but still don't
think its a good idea to hind side-effects, as although they may not be
fully leveraged at the moment, hiding them would seem to only hurt, and
never help in any circumstance. (But maybe I misunderstand the benefits of
hiding them, are there any?)

Re: converting Ada to handle USE_MAPPED_LOCATION

[Laurent GUERBY]

On Sat, 2005-03-19 at 11:52 -0800, Per Bothner wrote:

> && line not excessively big;
> The latter is a heuristic to avoid using up line number too greedily;
> I suspect it may not be an issue.

IIRC, current default max line length for Ada programs is 255, and 32767
for configuration pragmas. But it's always better to be prepared
for the worse :).

Laurent

Re: AVR indirect_jump addresses limited to 16 bits

[Marek Michalkiewicz]

On Sat, Mar 19, 2005 at 01:51:05PM -0500, Paul Schlie wrote:

> - Fully agree, just can't keep from wondering if this may be most
>   efficiency accomplish by simply requiring the alignment of all
>   function entry points to be two instruction word aligned. Thereby

This only doubles the available address space, and I'd rather not do
it all again (this time with 4-word alignment) if 512K chips appear.
Supporting the maximum possible address space on the AVR would require
64-word function alignment, and shifting the word address by 6.

But function entry points are not the only problem - indirect jumps are
another (as you can see in the subject of my message), they can point
somewhere within a function (so function alignment may not help here).
On the other hand, indirect_jump is rarely seen, so it must be correct
but doesn't have to be very efficient (OK if it costs even a few more
instructions to stay in the low 64K words).

So, I'm trying to figure out when the indirect_jump pattern can actually
be generated on the AVR (haven't yet seen it in any real application),
and where does the pointer comes from (to see if the jump target can be
moved to the low 64K words somehow).

Marek

Re: Question on tree-ssa-loop-im.c:for_each_index

[Zdenek Dvorak]

Hello,

> VIEW_CONVERT_EXPR is tcc_reference, but we can have a statement like:
> 
>   x =  22;

what is the semantics of this expression?  Should not this rather be

x =  22

(or just INTEGER_CST:some_type 22)?

Zdenek

> What ends up happening here is that find_interesting_uses_stmt calls
> find_interesting_uses_address, which goes down the references and
> runs into the constant, which it doesn't know how to handle.  I think
> the simplest fix is below.  It's certainly safe in that it converts
> an ICE into not aborting and seems to do the right thing.  The test case
> is in Ada and proprietary and it didn't seem worthwhile to make a small
> one for something this simple.
> 
> Does the following look correct?
> 
> *** tree-ssa-loop-im.c11 Mar 2005 09:05:10 -  2.31
> --- tree-ssa-loop-im.c19 Mar 2005 00:12:02 -
> *** for_each_index (tree *addr_p, bool (*cbc
> *** 195,198 
> --- 195,199 
>   case STRING_CST:
>   case RESULT_DECL:
> + case INTEGER_CST:
> return true;
>   

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> - Fully agree, just can't keep from wondering if this may be most
>>   efficiency accomplish by simply requiring the alignment of all
>>   function entry points to be two instruction word aligned. Thereby
> 
> This only doubles the available address space, and I'd rather not do
> it all again (this time with 4-word alignment) if 512K chips appear.

- understood, however unlikely; observing it will likely take Atmel at
  least 2-3 years to stabilize production of the 256K devices, and larger
  device volume potential vs. competitive offerings couldn't likely justify
  their development (as just an opinion).

> But function entry points are not the only problem - indirect jumps are
> another (as you can see in the subject of my message), they can point
> somewhere within a function (so function alignment may not help here).
> On the other hand, indirect_jump is rarely seen, so it must be correct
> but doesn't have to be very efficient (OK if it costs even a few more
> instructions to stay in the low 64K words).

- Sorry, I'm confused; can you give me an example of legal C expression
  specifying an indirect jump to an arbitrary location within a function?
  
  (as unless I misunderstand, there's no such thing?)

  I suspect they only exist as a result of a possible switch statement
  optimization strategy, which should have nothing to do with the size of
  the target's data pointers, therefore likely stored and accessed however
  convenient by the compiler in program memory (not data memory)
  independently of the representation chosen for function-pointers.

  (I'd guess)

> So, I'm trying to figure out when the indirect_jump pattern can actually
> be generated on the AVR (haven't yet seen it in any real application),
> and where does the pointer comes from (to see if the jump target can be
> moved to the low 64K words somehow).
> 
> Marek

Re: AVR indirect_jump addresses limited to 16 bits

[Marek Michalkiewicz]

On Sat, Mar 19, 2005 at 04:38:28PM -0500, Paul Schlie wrote:

> - understood, however unlikely; observing it will likely take Atmel at
>   least 2-3 years to stabilize production of the 256K devices, and larger
>   device volume potential vs. competitive offerings couldn't likely justify
>   their development (as just an opinion).

I thought the same about 128K devices, and then 256K devices appeared :)

> - Sorry, I'm confused; can you give me an example of legal C expression
>   specifying an indirect jump to an arbitrary location within a function?

Good question - I can't.  On the other hand, the manual says:

`indirect_jump'
An instruction to jump to an address which is operand zero.  *This pattern
name is mandatory on all machines.*

Why would it be mandatory if it was not truly needed?  If the manual is
correct, it seems this pattern is truly needed (not just an optional
optimization like some other patterns).

If it is impossible on the AVR, it could be implemented with invalid
assembler output (so we get an error if "impossible" ever happens).
But I'd like to be sure if this is really the case.  GCC is not only
a C compiler, perhaps indirect_jump is needed for some other language?

Thanks,
Marek

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
> Good question - I can't.  On the other hand, the manual says:
> 
> `indirect_jump'
> An instruction to jump to an address which is operand zero.  *This pattern
> name is mandatory on all machines.*
> 
> Why would it be mandatory if it was not truly needed?  If the manual is
> correct, it seems this pattern is truly needed (not just an optional
> optimization like some other patterns).
> 
> If it is impossible on the AVR, it could be implemented with invalid
> assembler output (so we get an error if "impossible" ever happens).
> But I'd like to be sure if this is really the case.  GCC is not only
> a C compiler, perhaps indirect_jump is needed for some other language?

- I believe it's simply a vehicle to allow the target describe how to
  jump indirectly to an address which may be required if the compiler
  chooses to generate a static jump table mapped into presumably the
  program's "text" section, therefore would guess the right thing to do
  would be to (assuming operand-0 is a progmem reference) load from
  progmem 2-words for 256K devices (or 1 word otherwise) into the
  appropriate registers, then executes an extended jump instruction
  (or regular jump otherwise).

  (as I'd hope the compiler would never map static jump tables that it
   chooses to generate into the "data" section, but can't find any
   description of under what circumstances it may generate/put them?)

(again, just my guess)

Re: AVR: CC0 to CCmode conversion

[Paul Schlie]

> From: Björn Haase <[EMAIL PROTECTED]>
> In my opinion segmenting the rework of the back-end would indeed be the best
> approach, also because I expect that the instruction patterns *with*
> splitting will be fairly different. E.g. I do not think that the "addsi3"
> will be present any more. So it would be probably a lot of useless work to
> add all of the clobbers for instruction patterns that are likely to vanish in
> the near future.

Related more specifically to the above comment:

- I understand the desire not to add stuff which is only likely to be
  removed/replaced in the near future.

- at that "near future" point in time, do you anticipate all side-effect
  STATUS-FLAG dependencies between split byte operations to be fully
  exposed such that it will guarantee that potential scheduling
  optimizations will never unsafely reorder them?

- in lieu of replacing the exiting target files with a short term
  interim solution, might it make sense to check-it-in as a parallel
  avr target description, which may be alternatively built with possibly
  --target=new-avr; thereby providing a convenient mechanism by which
  it could be both updated and experimented with conveniently without
  potentially disrupting the base-line existing target files; thereby
  when it's stabilized and clearly superior, it could replace the
  older ones, and then deleted (or kept as a experimental vehicle,
  to test further refinements without disrupting the base-line files?)

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Paul Schlie <[EMAIL PROTECTED]>
>> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> Good question - I can't.  On the other hand, the manual says:
>> 
>> `indirect_jump'
>> An instruction to jump to an address which is operand zero.  *This pattern
>> name is mandatory on all machines.*
>> 
>> Why would it be mandatory if it was not truly needed?  If the manual is
>> correct, it seems this pattern is truly needed (not just an optional
>> optimization like some other patterns).
>> 
>> If it is impossible on the AVR, it could be implemented with invalid
>> assembler output (so we get an error if "impossible" ever happens).
>> But I'd like to be sure if this is really the case.  GCC is not only
>> a C compiler, perhaps indirect_jump is needed for some other language?
> 
> - I believe it's simply a vehicle to allow the target describe how to
>   jump indirectly to an address which may be required if the compiler
>   chooses to generate a static jump table mapped into presumably the
>   program's "text" section, therefore would guess the right thing to do
>   would be to (assuming operand-0 is a progmem reference) load from
>   progmem 2-words for 256K devices (or 1 word otherwise) into the
>   appropriate registers, then executes an extended jump instruction
>   (or regular jump otherwise).
> 
>   (as I'd hope the compiler would never map static jump tables that it
>chooses to generate into the "data" section, but can't find any
>description of under what circumstances it may generate/put them?)
> 
> (again, just my guess)

- or possibly GCC may try to be clever by jumping to no-return attribute
  function calls?

gcc-4.0-20050319 is now available

[gccadmin]

Snapshot gcc-4.0-20050319 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050319/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050319 

You'll find:

gcc-4.0-20050319.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20050319.tar.bz2 C front end and core compiler

gcc-ada-4.0-20050319.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20050319.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20050319.tar.bz2  C++ front end and runtime

gcc-java-4.0-20050319.tar.bz2 Java front end and runtime

gcc-objc-4.0-20050319.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20050319.tar.bz2The GCC testsuite

Diffs from 4.0-20050312 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: converting Ada to handle USE_MAPPED_LOCATION

[Geert Bosch]

Hi Per,
Of the three proposals:
[...]
The ideal solution I think is for Ada to use line-map's 
source_location for Sloc in its lexer.
[...]
translate Sloc integers to source_location
when we translate the Ada intermal format to Gcc trees.
[...]
the location_t in the shared Gcc should be a language-defined opaque 
time,
and have language call-backs.
The first one really is out for the Ada maintainers, as this would 
couple
the front end far too tightly to the back end and lose the nice 
property that
the exact same front end sources (excluding the few C files for tree 
conversion)
can be used for any GCC back end from 2.8.1 to 4.1 without 
modifications, as
well as non-GCC back ends.

The second one wouldn't be my preferred choice, as it adds complexity 
for no
gain, but because the code can remain localized to the few C files 
interfacing
the front end to the back end, this would be acceptable.

The last would be far preferred, as it would not tie in front ends so 
much to the back
end, while still allowing sharing of the line map implementation when 
desired. As it both
seems easiest to implement, and cleanest. Clean separation from the 
back end is important
for languages maintained outside the GCC tree.

  -Geert

Re: AVR indirect_jump addresses limited to 16 bits

[Marek Michalkiewicz]

On Sat, Mar 19, 2005 at 06:37:54PM -0500, Paul Schlie wrote:

> - or possibly GCC may try to be clever by jumping to no-return attribute
>   function calls?

Such "trying to be clever" would most likely be optional.
Again, why is indirect_jump _mandatory_ on all machines?

Please, don't try to be too clever :) - just look at the GCC source
and try to figure out exactly what is indirect_jump used for, and how
much of this (if anything) matters for the AVR port.

If the address of a label is loaded into a register, then we have to
switch to a different section around that label:

/* ... */
jmp label
.section .text_low,"ax",@progbits
label:
jmp 1f
.text
1:
/* ... */

then it will be safe to load the address of the label into a register,
no need to do anything with the highest bits as pm_hh8(label) == 0:

ldi r30,pm_lo8(label)
ldi r31,pm_hi8(label)
/* ... */
ijmp; PC <- 0:r31:r30

Note that this adds two jumps around the label, so we only want to
do it infrequently - if the address of the label is loaded into
a register (not if the only users of the label are direct jumps).

Thanks,
Marek

Re: AVR indirect_jump addresses limited to 16 bits

[Giovanni Bajo]

Paul Schlie <[EMAIL PROTECTED]> wrote:

> - Sorry, I'm confused; can you give me an example of legal C
>   expression specifying an indirect jump to an arbitrary location
> within a function?


It is possible in GNU C at least:

int foo(int dest)
{
   __label__ l1, l2, l3;
   void *lb[] = { &&l1, &&l2, &&l3 };
   int x = 0;

   goto *lb[dest];

l1:
   x += 1;
l2:
   x += 1;
l3:
   x += 1;
   return x;
}

I would not design a backend so that such a feature is deemed to be impossible
to support.

Giovanni Bajo

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Brook]

On Sunday 20 March 2005 01:58, Giovanni Bajo wrote:
> Paul Schlie <[EMAIL PROTECTED]> wrote:
> > - Sorry, I'm confused; can you give me an example of legal C
> >   expression specifying an indirect jump to an arbitrary location
> > within a function?
>
> It is possible in GNU C at least:
>
> int foo(int dest)
> {
>__label__ l1, l2, l3;
>void *lb[] = { &&l1, &&l2, &&l3 };
>int x = 0;
>
>goto *lb[dest];
>
> l1:
>x += 1;
> l2:
>x += 1;
> l3:
>x += 1;
>return x;
> }
>
> I would not design a backend so that such a feature is deemed to be
> impossible to support.

Don't we know which labels are targets of indirect jumps?
So the proposed restriction now becomes: functions *and targets of indirect 
jumps* must be aligned to an N word boundary. I'd guess that the latter are 
sufficiently rare that this is still an acceptable restriction.

Paul

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Giovanni Bajo <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> - Sorry, I'm confused; can you give me an example of legal C
>>   expression specifying an indirect jump to an arbitrary location
>>   within a function?
> It is possible in GNU C at least:

- thanks, obviously wasn't aware of that.

(which unfortunately creates an interesting problem; which may not
 be as worth trying to solve, as investing in other improvements
 which may generally benefit all devices)

Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie]

> From: Paul Brook <[EMAIL PROTECTED]>
> Don't we know which labels are targets of indirect jumps?
> So the proposed restriction now becomes: functions *and targets of indirect
> jumps* must be aligned to an N word boundary. I'd guess that the latter are
> sufficiently rare that this is still an acceptable restriction.

- seams plausible, if it were reasonably easy to identify such labels to the
linker with a corresponding alignment requirement to the exclusion of all
other labels? (and the restricted alignment method were deemed acceptable?)

Re: For those who want to automatically generate predicates.md...

[Bob Wilson]

Kazu Hirata wrote:
I created a set of scripts that generates predicates.md based on
PREDICATE_CODES in tm.h.
Thank you!  I had been planning to do this for the Xtensa port, but your scripts 
motivated me to do it sooner.  I ended up rewriting most of the predicates in 
Lisp-style, but the scripts were still helpful.  I'll post the patch soon. 
Thanks again.

--Bob

[AVR] RTL prologue/epilogue

[HutchinsonAndy]

Attached is patched for 4.1.0 head that changes AVR to use RTL 
prologue/epilogue generation.

This also should also fix the c++ bug caused by the existing code using the 
function name as a label. (sorry the PR escapes me!)


It generates same code with following exceptions:

Small stack adjustments are made using "rcall ." (2 bytes) and "push r0" (1 
byte). This avoids difficult direct manipulation of stack pointer when it is 
less efficient. Choice is based on instruction size - but thats pretty close to 
speed.

All stack pointer loads are now handled by move_hi code. This removes 
duplicated tests and simplifies code.

Various unspecs have been added to generate the required abnormal RTL 
instructions and where gcc want to remove things (usually to do with register 
push/pops for r0/r1). 

Asm comments are different - limited by RTL. However they convey same 
information if not more descriptive.

...and hopefully the code's right!

Comments on accuracy and style please.


-- 
Andy Hutchinson


__
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp


patch.txt.bz2
Description: patch.txt.bz2