For the instant, I am learning for how GCC work, and for the definition
of machines descriptor. I founded the GCC port for PIC30, but it 's very
far of the PIC18.
I also seen the IP2022 port, and it will be helpfull.
In the Microchip PIC, there is only one Work register, but all the RAM
memory acc
> everything else in data memory (which they use in the manner of a
> register file)...IDK how well GCC's register allocator would handle
> such a thing...
For the m32c, I ended up describing 8 "registers" that were really
memory. It gave gcc something to work with at least, but you have to
get
I'm sorry about my e-mail client mangling your name in the To: field.
I don't know about the Microchip source, but I'd be happy to help with
the GCC->PIC18Fxxx port...however, PIC's have 1 true accumulator (W) and
everything else in data memory (which they use in the manner of a
register file)
Hello,
I am talking about porting GCC on PIC18Fxxx, by Microchip.
I found some source code from Microchip to support the PIC30F. Anyone
can tell me why this code isn't in the gcc tree ? Is it dirty code ?
I ask this question, cause I maybe re-use that source code for testing.
Best Regards,
--
On Mon, Jan 30, 2006 at 10:31:18AM -0800, H. J. Lu wrote:
> Does that mean DWARF2_UNWIND_INFO should be checked before using
> INCOMING_RETURN_ADDR_RTX instead of checking INCOMING_RETURN_ADDR_RTX?
Yes. But as-quoted, it already is.
r~
> I'm trying to get:
>
> void foo() {
>int rowfraclo[2];
>rowfraclo[1] = 42;
>asm ("movd mm6, %a0" : : "p" (rowfraclo+1));
> }
>
> With the below patch (still running the testsuite) I can get the
> compiler to generate that code. So, the question is how better can I
> do this?
I
> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
>> ecj is written in java. This will complicate the bootstrap process.
Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
We don't know how much of the language that would be.
Tom
I'm trying to get:
void foo() {
int rowfraclo[2];
rowfraclo[1] = 42;
asm ("movd mm6, %a0" : : "p" (rowfraclo+1));
}
to generate:
movd mm6, -4(%ebp)
at -O0. Currently we generate:
leal-8(%ebp), %eax
addl$4, %eax
movd mm6, (%eax)
With the below patch (still running
gimplify.c:gimplify_modify_expr_rhs tries to optimize calls to functions
which return their value in memory, if the result is assigned to a
variable, by using the address of that variable as the location where
the result is top be stored. It uses lang_hooks.mark_addressable to
mark the variabl
On Jan 30, 2006, at 9:50 AM, murali wrote:
I am trying to change the number of registers for simplescalar's gcc
(2.7.2.3) compiler.
It is unlikely we're going to help much with 2.7.2.3, we'd recommend
up-porting to gcc 4.2 to start with.
On Mon, Jan 30, 2006 at 10:26:44AM -0800, Richard Henderson wrote:
> On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> > Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> > with an ifdef)?
>
> That would be wrong. INCOMING_RETURN_ADDR_RTX is *required*
> wh
On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> with an ifdef)?
That would be wrong. INCOMING_RETURN_ADDR_RTX is *required*
when defining DWARF2_UNWIND_INFO.
But DWARF2_UNWIND_INFO shouldn't be defined
Hi,
I'm sorry, but as this is only a general contact address, I cannot
properly answer technical questions such as yours. The best I can do is
refer you to the GCC Manual (http://gcc.gnu.org/onlinedocs/) and Frequently
Asked Questions (http://gcc.gnu.org/faq.html). If neither of those provide
an
Quoting Rainer Orth <[EMAIL PROTECTED]>:
Aleksandar Milivojevic <[EMAIL PROTECTED]> writes:
Was there any work (or plans) on porting libmudflap to Solaris (either
SPARC or x86)?
Last time I looked (cf. PR libmudflap/15176), libmudflap depended on GNU
ld's --wrap option. You might have some
Hi,
I am trying to change the number of registers for simplescalar's gcc
(2.7.2.3) compiler. I modified the ss.h file - FIXED_REGISTERS bits
and CALL_USED_REGISTERS bits, so as to leave just 8 integer and 4 FP
registers. But when I do a live registers analysis, I get > 8 integer
registers live.
Aleksandar Milivojevic <[EMAIL PROTECTED]> writes:
> Was there any work (or plans) on porting libmudflap to Solaris (either
> SPARC or x86)?
Last time I looked (cf. PR libmudflap/15176), libmudflap depended on GNU
ld's --wrap option. You might have some success when you use GNU binutils,
but I
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> In particular, the type system and the rules for exception
> Andrew> regions are different. Also, a "slot" in the .class format
> Andrew> doesn't necessarily correspond to a variable in the source
>
Hi,
we're currently developing an experimental back-end for a very
irregular DSP architecture violating very basic assumptions of the
gcc back-end. In order to have the option to switch the front-end
for experimental reasons and to have a clear interface to gcc, we
chose to decouple the back-end
Was there any work (or plans) on porting libmudflap to Solaris (either
SPARC or x86)?
This message was sent using IMP, the Internet Messaging Program.
Bernd Schmidt wrote:
Joern RENNECKE wrote:
Because the new code as of December actually updated life information
incorrectly, the global updates that were done had also quite a lot
of work to do (and didn't really do it right, because of the presence
of fake edges).
Could you elaborate on
Paolo's recent post on gcc-patches reminded me of all the toplevel
libgcc changes I have pending. To recap, the dependence is: if libgcc
is moved out of the top level, the "configure --disable-bootstrap; make
bootstrap" approach will no longer work. Building without a bootstrap
will be fine, of c
Tom Tromey dixit:
>In my preferred approach we would simply delete a portion of the
>existing gcj and turn jc1 into a purely bytecode-based compiler.
>ecj is written in java. This will complicate the bootstrap process.
Why not keep enough support in jc1 to bootstrap ecj?
Maybe split out so that
22 matches
Mail list logo
