On Mon, Oct 02, 2006 at 12:42:04PM +0200, Wolfgang Mües wrote:
> Now it's time to give a big "thank you" to all persons involved,
> ecpecially Rask Ingemann Lambertsen with his invaluable help.
>
> As I started this project, I feared that I would never succeed, and
> now ... the modified compile
Now it's time to give a big "thank you" to all persons involved,
ecpecially Rask Ingemann Lambertsen with his invaluable help.
As I started this project, I feared that I would never succeed, and
now ... the modified compiler is used about 3 month now, and DSLINUX
with this crude modification is
Rask,
On Sunday 06 August 2006 02:05, Rask Ingemann Lambertsen wrote:
> Yes, it only cures the symptom, but it could take a lot of time to
> find the cause, and the gain is small, so I think it is OK to leave
> it like this for now.
OK.
> This insn was generated from the "reload_outqi" pattern. I
On Sat, Aug 05, 2006 at 09:03:34PM +0200, Wolfgang Mües wrote:
> First, I have had a problem with loading a register with a constant.
> (no clobber). I have solved this problem by adding
>
> > (define_insn "_arm_movqi_insn_const"
[cut]
>
> I am very shure that this does only cure the symptoms, a
Rask,
On Friday 21 July 2006 15:26, Rask Ingemann Lambertsen wrote:
> I found that this peephole optimization improves the code a whole
> lot:
Done.
> Another way of improving the code was to swap the order of the two
> last alternatives of _arm_movqi_insn_swp.
Done.
Anyway, the problems with
On Thu, Jul 20, 2006 at 04:37:41PM +0200, Rask Ingemann Lambertsen wrote:
> ;; This is primarily a hack for the Nintendo DS external RAM.
> (define_insn "_arm_movqi_insn_swp"
> [(set (match_operand:QI 0 "reg_or_Qmem_operand" "=r,r,r,Q,Q")
> (match_operand:QI 1 "general_operand" "rI,K,m,r,r"
On Thu, Jul 20, 2006 at 03:27:49PM +0200, Rask Ingemann Lambertsen wrote:
> (define_expand "reload_outqi"
> [(clobber (match_operand:QI 0 "memory_operand" "=Q"))
>(clobber (match_operand:DI 2 "register_operand" "=&r"))
>(set (match_dup 4) (match_dup 5))
>(parallel [
>(set (match_
On 20 July 2006 16:25, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Is there any generic advice available as to when and why one should use
>> emit_insn (gen_rtx_SET ()) as opposed to emit_move_insn (...)?
>
> It depends on where you are in the compiler. You can
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Is there any generic advice available as to when and why one should use
> emit_insn (gen_rtx_SET ()) as opposed to emit_move_insn (...)?
It depends on where you are in the compiler. You can only use
gen_rtx_SET if you know that the resulting insn w
On Wed, Jun 07, 2006 at 07:22:31AM +0200, Wolfgang Mües wrote:
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
>
> > Yet another register which stands a good chance of being reusable is
> > the register containing the address.
>
> Yes, but that is not allowed according to the spe
On Thu, Jul 20, 2006 at 08:02:45AM +0200, Wolfgang Mües wrote:
> But it's not the only function which uses gen_rtx_SET. There are also
> much places with
>
> > emit_constant_insn (cond,
> > gen_rtx_SET (VOIDmode, target, source));
>
> Isn't it better to replace gen_rtx_SET?
gen_rtx_SET()
On Thu, 2006-07-20 at 12:04, Dave Korn wrote:
> On 20 July 2006 07:03, Wolfgang Mües wrote:
>
> > Hello Rask,
> >
> > On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> >> I've spotted a function named emit_set_insn() in arm.c. It might be
> >> the problem, because it uses gen_rtx
On 20 July 2006 07:03, Wolfgang Mües wrote:
> Hello Rask,
>
> On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
>> I've spotted a function named emit_set_insn() in arm.c. It might be
>> the problem, because it uses gen_rtx_SET() directly.
>
> But it's not the only function which u
Hello Rask,
On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> I've spotted a function named emit_set_insn() in arm.c. It might be
> the problem, because it uses gen_rtx_SET() directly.
But it's not the only function which uses gen_rtx_SET. There are also
much places with
> e
On Wed, Jul 19, 2006 at 01:24:59PM +0200, Rask Ingemann Lambertsen wrote:
>
> The function named emit_move_insn() ought to do the trick here, but
> is perhaps a bit heavyweight for this purpose. Anyway, try this patch
> (untested), which should plug this particular hole:
There was an unbalanced p
On Wed, Jul 19, 2006 at 07:52:32AM +0200, Wolfgang Mües wrote:
> Hello,
>
> after getting a "working" version of the gcc 4.0.2 with the Nintendo
> 8-bit-write problem, I was busy the last weeks trying to adapt the
> linux system (replacing I/O with writeb() macros, removing strb
> assembler cal
Hello,
after getting a "working" version of the gcc 4.0.2 with the Nintendo
8-bit-write problem, I was busy the last weeks trying to adapt the
linux system (replacing I/O with writeb() macros, removing strb
assembler calls).
However, it turned out that the sources of the linux kernel are a far
On Fri, Jun 02, 2006 at 09:24:17AM +0200, Rask Ingemann Lambertsen wrote:
> The rest of the ARM backend presently assumes that the pattern has the form
>
> (set (operand:QI 0) (operand:QI 1))
>
> but now we've changed it to
>
> (parallel [(set (operand:QI 0) (operand:QI 1))
> (clobber
On Thu, Jun 08, 2006 at 11:02:12PM +0200, Wolfgang Mües wrote:
> Rask,
>
> > arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> > -ffast-math -mthumb-interwork -isystem
> > /usr/lib/devkitpro/libnds/include -mcpu=arm9tdmi -mtune=arm9tdmi
> > -DARM9 -S arm9_main.c -o arm9_main.S arm9
Rask,
On Thursday 08 June 2006 20:12, Rask Ingemann Lambertsen wrote:
> Also, undo the change to arm_legitimate_address_p() arm.c.
Hmmm
> arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> -ffast-math -mthumb-interwork -isystem
> /usr/lib/devkitpro/libnds/include -mcpu=arm9td
On Tue, Jun 06, 2006 at 08:27:10PM +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> > This is just a guess, but the insn above might be an output reload.
>
> It is, in a peculiar (and not useful) way. Diffing the greg dump against
> the
On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote:
> Rask,
>
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> > >
> > > You should get a price for cleverness here!
> >
> > Thanks! Indeed it looks good until you think of volatile va
Rask,
On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> >
> > You should get a price for cleverness here!
>
> Thanks! Indeed it looks good until you think of volatile variables.
Because volatile variables can change their values from
On Tue, Jun 06, 2006 at 07:42:20AM +0200, Wolfgang Mües wrote:
> Rask,
>
> On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote:
> > I think the comment in arm.h is wrong. The manual seems to agree with
> > the code.
>
> Just to make it easy for beginners...
In mainline GCC, it is defin
On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> Wolfgang Mües <[EMAIL PROTECTED]> writes:
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
> >> __register_frame_info_table_bases':
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
> >> satisfy its
Wolfgang Mües <[EMAIL PROTECTED]> writes:
> On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
>> On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
>> > > (define_insn "*arm_movqi_insn"
>> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
>> > > (match_oper
Rask,
On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote:
> On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote:
> Does GCC happen to accept "[%r, #0]" for swp?
No. But no problem here to change that.
> I think the comment in arm.h is wrong. The manual seems to agree with
> t
On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote:
> I don't know why the form "[%r, #0]" was coded before, because the
> assembler understands "[%r]" very well for all instructions. The form
> "[%r]" has a wider usage because it covers swp too.
Does GCC happen to accept "[%r, #0]"
> > Tightening the predicates isn't sufficient (and may not even be
> > neccessary). You need to set the constraints so that the compiler
> > knows *how* to fix invalid instructions.
>
> And if I have 4 different constraints in a single insn, and only one of
> them is needing a temporary register,
On Mon, 2006-06-05 at 12:47, Wolfgang Mües wrote:
> > /* Output the address of an operand. */
> > #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)\
> > { \
> > int is_minus = GET_CODE (X) == MINUS;
Hello,
my first little success...
in arm.h, I have changed
> /* Output the address of an operand. */
> #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X) \
> { \
> int is_minus = GET_CODE (X) == MINUS;
Richard,
On Monday 05 June 2006 12:06, Richard Earnshaw wrote:
> I'm confident right now that these will be too invasive to include in
> mainline.
As said before, this is OK for me.
> The changes that tend to get incorporated into the compiler are to
> work around bugs in the CPU, not bugs in s
Hello Dave ;-)
On Monday 05 June 2006 02:12, Dave Murphy wrote:
> I was just about to ask about this very thing since I'm quite sure
> that there would be interest in adding this to devkitARM.
You are following the process in dslinux, don't you?
In fact, devkitARM is my current build environment
On Sun, 2006-06-04 at 22:01, Rask Ingemann Lambertsen wrote:
> On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote:
>
> > For the record these hacks are unlikely to ever be acceptable in mainline
> > gcc.
> > They're relatively invasive changes who's only purpose is to support
> > fundam
Paul,
On Sunday 04 June 2006 17:57, Paul Brook wrote:
> Because then you have several different patterns for the same
> operation. The different variants of movsi should be part of the same
> pattern so that the compiler can change its mind which variant it
> wants to use.
Together with the comme
Rask Ingemann Lambertsen wrote:
There are other targets with targets specific options to work around this or
that bug, quirk, defect or errata. In this case, why would two options
-mno-byte-writes and -mbyte-writes, with the latter being the default, be
unlikely to be acceptable? In particular, t
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
> > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
> > "TARGET_ARM
> >&& ( register_operand (operands[0], QImode)
>
On Sun, Jun 04, 2006 at 05:26:42PM +0200, Wolfgang Mües wrote:
> Paul,
>
> On Sunday 04 June 2006 13:24, Paul Brook wrote:
>
> > You should just change the valid QImode memory addresses, adding a new
> > constraint if neccessary.
>
> H... I have tried this. I have changed the operand const
On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote:
> For the record these hacks are unlikely to ever be acceptable in mainline
> gcc.
> They're relatively invasive changes who's only purpose is to support
> fundamentally broken hardware.
We don't yet know if they'll be invasive. There
On Sun, Jun 04, 2006 at 12:31:08PM +0200, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1
On Sunday 04 June 2006 16:26, Wolfgang Mües wrote:
> Paul,
>
> On Sunday 04 June 2006 13:24, Paul Brook wrote:
> > On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> > > Splitting the insn
> > >
> > > (define_insn "*arm_movqi_insn"
> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,
Paul,
On Sunday 04 June 2006 13:24, Paul Brook wrote:
> On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> > Splitting the insn
> >
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
> > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
>
On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1, [%M0]" that
Hello Rask,
On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> There may be a faster way of seeing if the modification is going to
> work for the DS at all. I noticed from the output template
> "swp%?b\\t%1, %1, [%M0]" that "swp" takes three operands. I don't
> know ARM assembler, but
On Fri, Jun 02, 2006 at 08:23:49AM +0200, Wolfgang Mües wrote:
> Rask,
>
> (_only_ adding the clobber statement),
> I get
> >0/newlib/li bc/argz/argz_create_sep.c:60: error: unrecognizable insn:
> (insn 192 21 24 0 (set (reg:QI 1 r1) (reg:QI 4 r4)) -1
> (nil) (nil))
>
> What do you mean wit
Rask,
On Thursday 01 June 2006 16:13, Rask Ingemann Lambertsen wrote:
> I think you will need to remove the '+' as already suggested and add
> (clobber (match_scratch:QI "=X,X,X,1")) to tell GCC that the register
> allocated to operand 1 is clobbered by the instruction for this
> particular altern
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,Q")
> > (match_operand:QI 1 "general_operand" "rI,K,m,+r"))]
> > "TARGET_ARM
> >&& ( register_operand (operands[0], QImode)
>
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,Q")
> > (match_operand:QI 1 "general_operand" "rI,K,m,+r"))]
> Changing "m" to "Q", narrowing the address modes
> Changing "r" to "+r", (register is globbered)
This is wrong. the "+" applies to th
Paul,
thank you for commenting...
On Tuesday 30 May 2006 22:03, Paul Brook wrote:
> > I found arm.md and the moveqi insns, but because of the different
> > addressing modes of strb and swpb, its not easy to make the change.
> > And there must be a compiler option for this, too.
> >
> > Could some
On Tuesday 30 May 2006 23:47, Daniel Jacobowitz wrote:
> On Tue, May 30, 2006 at 09:03:54PM +0100, Paul Brook wrote:
> > > I found arm.md and the moveqi insns, but because of the different
> > > addressing modes of strb and swpb, its not easy to make the
> > > change. And there must be a compiler o
> > There are a couple of complications that spring to mind. The different
> > addressing modes and the fact that swp clobbers a register are the most
> > immediate ones.
> >
> > You'll need to modify at least the movqi insn patterns, memory
> > constraints and the legitimate address stuff. I'm not
On Tue, May 30, 2006 at 09:03:54PM +0100, Paul Brook wrote:
> > I found arm.md and the moveqi insns, but because of the different
> > addressing modes of strb and swpb, its not easy to make the change.
> > And there must be a compiler option for this, too.
> >
> > Could somebody please tell me how
> I found arm.md and the moveqi insns, but because of the different
> addressing modes of strb and swpb, its not easy to make the change.
> And there must be a compiler option for this, too.
>
> Could somebody please tell me how to implement this change?
Short answer is probably not.
There are a
Hello,
I am trying to port big C/C++ programs (see www.dslinux.org) to the
nintendo DS console.
The console has 4 Mbytes internal memory, and 32 MBytes external
memory which is *not* 8bit writable (only 16 and 32 bits). CPU is an ARM
946. Using the external memory for ROM(XIP) and the internal
54 matches
Mail list logo
