Subject:
|
Re: memcpy patch for gcc 2.95.2 wanted
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sun, 26 Mar 2000 09:17:35 GMT
|
Viewed:
|
2336 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Luis Villa writes:
> On Sun, 26 Mar 2000, Ben Jackson wrote:
> > In lugnet.robotics.rcx.legos, Rossz V=E1mos-Wentworth writes:
> > > In an attempt to track down my RCX lockup problems I've been rereading
> > > the older messages and came across the discussion that sounded exactly
> > > like my problem: the RCX locks up when dll is executed. The conclusion
> > > was that bad code was generated for the memcpy function, but I didn't
> > > see a solution posted.
> > =20
> > That was probably me. I don't know anything about GCC asm macros so I wa= • sn't
> > sure if it was a bug in memcpy or a bug in GCC's code generation. I solv= • ed the
> > problem by going to egcs-1.1.2 which generates correct code. I was hopin= • g that
> > someone else would take it from there!
> > =20
>
> Sorry... I was going to recommend the same thing last night, but got=20
> sidetracked (it has been a tough two days to be a Duke basketball fan.) I=
> =20
> have a question: from where in the code is the incorrect assembly=20
> generated?
I think the compiler was generating incorrect code. I'm no gcc expert, but the
asm macros looked OK to me, and besides, why should the macro work in one
compiler version & not the other?
FYI, I fixed it by compiling the source to an assembler file (using -S), then
hacking the assembler file. Just remove memcpy.c from the build tree and leave
memcpy.s in its place. Beware the 'make realclean' will remove all '.s' files.
Here's a copy of the fixed assembler code, memcpy.s:
; GCC For the Hitachi H8/300
; By Hitachi America Ltd and Cygnus Support
; release F-1
; -O2
.file "memcpy.c"
.section .text
.align 1
.global _memcpy
_memcpy:
mov.w r1,r3
add.w r2,r3
; #APP
0:cmp r1,r3
beq 1f
mov.b @r1+,r2l
mov.b r2l,@r0
adds #1,r0
bra 0b
1:
; #NO_APP
rts
.end
|
|
Message has 2 Replies:
 | | Re: memcpy patch for gcc 2.95.2 wanted
|
| Les Smithson <lsmithso@hare.demon.co.uk> wrote in message news:Fs0v5B.J44@lugnet.com... (...) You saved me the trouble of posting the exact same fix. Thanks. I'm concerned there might be other problems caused by this bug. Fixing this routine treats (...) (25 years ago, 26-Mar-00, to lugnet.robotics.rcx.legos)
| | | Re: memcpy patch for gcc 2.95.2 wanted
|
| (...) Because there were some decisions made as to what "incorrect" macros were and weren't by the egcs/gcc teams. For some time, this made compiling the Linux kernel with the newest egcs a serious problem. (...) Cool. -Luis (...) ###...### (...) (25 years ago, 26-Mar-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: memcpy patch for gcc 2.95.2 wanted
|
| (...) Sorry... I was going to recommend the same thing last night, but got sidetracked (it has been a tough two days to be a Duke basketball fan.) I have a question: from where in the code is the incorrect assembly generated? i.e., could it be (...) (25 years ago, 26-Mar-00, to lugnet.robotics.rcx.legos)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
