> > If I understand correctly it complains about a move instruction where src
> > memory location should be (reg22+reg23). My arch defines:
> > #define MAX_REGS_PER_ADDRESS 1
> > the first pseudo reg is 13
> >
>
> I think the wording of the second sentence in the M_R_P_A documentation
> (beginn
On 01/08/2010 16:26, Gabor Kerenyi wrote:
> I'm porting GCC 4.4.4 to a new arch and while cross-compiling libgcc I get
> the
> following error:
> ../../../libgcc/../gcc/libgcc2.c: In function ‘__clzsi2’:
> ../../../libgcc/../gcc/libgcc2.c:716: error: unrecognizable insn:
> (insn 49 48 50 16 ../.
On 10/02/2010 19:19, Sergio Ruocco wrote:
> It seems that prologue()/epilogue() are called quite late in the
> compiling process, thus new registers cannot be created (no_new_pseudos
> assert fires) and/or emit_move_insn() does not go through
> LEGITIMIZE_ADDRESS()... will work on this tomorrow...
I found the source of my problems!
The prologue()/epilogue() functions (*) I took from the tutorial written
for SPIM/MIPS emit a number of move insn to/from "invalid" memory
addresses (reg+off) that do not go through LEGITIMIZE_ADDRESS(), and
this freaks out GCC, so I have to rewrite these in som
Thanks Micheal for your code, I will try it... however, I think the
problem that crashes my compiler may not lie in my LEGITIMATE/LEGITIMIZE
ADDRESS macros, which are equivalent to many others (yours included),
but in the GCC which - in some corner cases - does not like being told
that an registe
Hi Sergio. Here's the interesting parts from my port. The code's a
bit funny looking as I've edited it for this post.
In .h:
#define BASE_REG_CLASS ADDR_REGS
#define INDEX_REG_CLASS NO_REGS
#ifdef REG_OK_STRICT
# define _REG_OK_STRICT 1
#else
# define _REG_OK_STRICT 0
#endif
#define REGNO_OK
Michael Hope wrote:
> Hi Sergio. Any luck so far?
Micheal, thanks for your inquiry. I made some progress, in fact.
I got the GO_IF_LEGITIMATE_ADDRESS() macro to detect correctly REG+IMM
addresses, and then the LEGITIMIZE_ADDRESS() macro to force them to be
pre-computed in a register.
However,
Now my GO_IF_LEGITIMATE_ADDRESS refuses anything that is not a REG
or a CONSTANT_ADDRESS:
int legitimate_address1(enum machine_mode MODE,rtx X)
{
if(CONSTANT_ADDRESS_P(X))
return 1;
if(GET_CODE(X)==REG && is_base_reg(REGNO(X)))
return 1;
r
Hi Sergio. My port has similar addressing modes - all memory must be
accessed by one of two registers and can only be accessed indirectly,
indirect with pre increment, and indirect with post increment. The
key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
function. Mine looks lik
On 01/25/10 11:21, Sergio Ruocco wrote:
Gabriel Paubert wrote:
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpos
Gabriel Paubert wrote:
> On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
>> Hi everyone,
>>
>> I am porting GCC to a custom 16-bit microcontroller with very limited
>> addressing modes. Basically, it can only load/store using a (general
>> purpose) register as the address, without an
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
>
> Hi everyone,
>
> I am porting GCC to a custom 16-bit microcontroller with very limited
> addressing modes. Basically, it can only load/store using a (general
> purpose) register as the address, without any offset:
>
> LOAD
On Thu, 2009-07-30 at 23:58 +0100, Robert Oeffner wrote:
> Until now there is no compiler available for interix that supports OpenMP
> and that's what I'm after. As libgomp in GCC so far isn't targeting interix
> I have made some changes to libgomp in my copy of the GCC 4.4.0
> distribution.
l
Aurélien Buhrig <[EMAIL PROTECTED]> writes:
> We are designing a 16-bit asynchronous microcontroller. I’ve already ported
> bfd, binutils (including sid simulator) using cgen, and part of gdb (for asm
> debug only) and we are now investigating the best way to have C compiler.
> So my questions are
> I have need to compile code for an old ARC tangent A4 core.
> 1) Gcc 3.x does support ARC Tangent-A4
> 2) Gcc 4.x dose support ARC Tangent-A4
Both contain a port which in principle targets the ARCtangent-A4.
I don't know if it actually works, it might be subject to bitrot.
We at ARC have a mor
On Wed, 2008-03-12 at 16:56 +1100, Schmave wrote:
> Hi I would luke to know what I need to do to port gcc to a new
> architecture
You can start by reading the GCC internals documentation:
http://gcc.gnu.org/onlinedocs/gccint/
You can also look at the source code, in particular, the gcc/confi
> > I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
> > simplest c54x.h and c54x.c and a empty md, and I
>
> I think the answer is right there
> ^^
IIRC what you need as a bare minimum as a w
On Wed, 12 Dec 2007, a2220333 wrote:
> hi,
> I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
> simplest c54x.h and c54x.c and a empty md, and I
I think the answer is right there
^^
> compil
Alexandre Tzannes <[EMAIL PROTECTED]> writes:
> I'm Alex Tzannes and I am porting GCC 4.0.2 to a new experimental parallel
> architecture. Here's one issue I don't know how to go about. The ISA of
> our machine is based on MIPS (so I made a copy of the MIPS back end and
> have been modifying that)
Mans <[EMAIL PROTECTED]> writes:
> Hi i've been put into a project in which the GDB residing on the host machine
> should control the programs running on the target(wic has its (own made)
> specific processor); I am very much new into all this and as my first task
> : i have been assigned the ta
On Tuesday 26 September 2006 20:09, Dave Korn wrote:
> On 26 September 2006 20:01, max blomme wrote:
> > I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> > a bit overwhelmed.
> >
> > Looking through some of the documentation (there's quite a lot of it!) I
> > can't seem to
On 26 September 2006 20:01, max blomme wrote:
> I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> a bit overwhelmed.
>
> Looking through some of the documentation (there's quite a lot of it!) I
> can't seem to find the answers to a few questions. Pardon me if they
> seem
[EMAIL PROTECTED] (Leif Ekblad) wrote on 30.12.05 in <[EMAIL PROTECTED]>:
> Mike Stump:
> > make will build libgcc for the target, specifically, you should be
> > able to cd gcc && make libgcc.a to build it.
>
> It did when I added --host=rdos to the configuration script and
> changed a couple of
Mike Stump:
> make will build libgcc for the target, specifically, you should be
> able to cd gcc && make libgcc.a to build it.
It did when I added --host=rdos to the configuration script and
changed a couple of other files. My only current problem is that
since RDOS uses the .exe suffix for exe
On Dec 29, 2005, at 1:01 PM, Leif Ekblad wrote:
OK, I found unwind-dw2.c in the GCC directory. I also found
the object files in the linux host directory, but not in the RDOS
cross
compilation directory. I cannot run the GCC configuration process
natively on RDOS (yet), so I must somehow build
Where are these functions implemented
Mike Stump:
grep will show you the code that should be used to build it. unwind-
dw2.c is the usual place.
OK, I found unwind-dw2.c in the GCC directory. I also found
the object files in the linux host directory, but not in the RDOS cross
compilation di
On Dec 29, 2005, at 11:45 AM, Leif Ekblad wrote:
However, now I still get unresolved externals related to C++
exception-handling (_Unwind_resume
and so on).
mrs $ nm libgcc_s.1.dylib | grep Unwind_Re
8c24 T __Unwind_Resume
mrs $ nm libgcc/unwind-dw2.o | grep Unwind_Res
24c0 T __Unwind
<[EMAIL PROTECTED]> writes:
> The original intention was that CGEN would eventually be able to
> generate the MD file for GCC. When I last used CGEN 2 years ago, it
> was not able to do that at the time, and I suspect the problem is
> very complex for real machines [...]
There exists a CGEN/SID
20, 2005 5:43 PM
To: Meissner, Michael
Cc: [EMAIL PROTECTED]
Subject: RE: porting gcc/binutils
Hi Michael,
first, thanks for your detailed instructions
> If your target is a regular target like a RISC platform, the CGEN system
> can be used to simplify building the instructio
> I have already stumbled over cgen on the net and skimmed the
> manual. I have noticed that it uses RTL CPU descriptions, I hope
> this code can be reused for gcc machine description file.
Nope. The only thing cgen's RTL and gcc's RTL share is the acronym.
Hi Michael,
first, thanks for your detailed instructions
> If your target is a regular target like a RISC platform, the CGEN system
> can be used to simplify building the instruction tables:
> http://sourceware.org/cgen/
>
I have already stumbled over cgen on the net and skimmed the manual.
When I used to work for Cygnus Solutions (and then Red Hat after they
bought Cygnus in 1999), the general port to an embedded target was
typically done in parallel by 3 people (or 3 groups for large ports).
Before starting out, somebody would design the ABI (either customer
paying for the port, the
Andrija Radičević wrote:
> I'm trying to port gcc and binutils to a new target and I hoped to find
> a brief procedure on that matter on the net, but was unsuccessful. OK,
> the GCC internals is quite a resourceful document and one can learn a
> lot by examining the source tree, but It would be ver
On Dec 14, 2005, at 3:31 PM, Andrija Radičević wrote:
I'm trying to port gcc and binutils to a new target and I hoped to
find
a brief procedure on that matter on the net, but was unsuccessful. OK,
the GCC internals is quite a resourceful document and one can learn a
lot by examining the source
Original Message
>From: Eric Fisher
>Sent: 01 September 2005 09:43
> Hello,
>
> Here is a question about porting gcc. After I modified machine.md and
> other backend files, I can make cc1 and xgcc now. But libgcc2.o still
> failed. I'd like to know does we must make libgcc2.o since the t
35 matches
Mail list logo
