Re: C integrated RPC
In attach you can find example program,
client and server side. And doc for the system as README file.
The newest version of the sources can be downloaded from
crpc at sf dot net.
To compile the package just 'make' and 'make install'. Tests can be
found inside the tests
directory.
There are several differences between CRPC and traditinal RPC systems.
So it has no discriptive language like IDL, everything needed is taken
from the C code.
The goal of the system is to be as easy as possible.
With CRPC you do not need to give static identifiers for remote
functions, you should only
use two new modificators - __remote (to declare client function) and __local
(to declare server function). ID for the function will be computed by
wrapper compiler, as
32-bit checksum of function prototype text. With CRPC you don't need to pack
data before sending trough the net, every thing is automatically. Also CRPC
can work with pointer addressed data, I added a special __attribute__ statement,
which can tell the size addressed by the pointer. CRPC can send any data types,
any structs.
Also __in and __out modificators are available for the function
parameters, which tells
the system to send data only to the server or only fill some array on
the server. The default
mode is to send data to the server, change it there and get it back on client.
CRPC wrapper compiler can work with make and can be used 'instead' of
the GCC, as it
covers it. The wrapper compiler works between the preprocessor and
main C compiler.
Shared libraries can be biuld with this compiler. Also such __remote
functions can be
used with another servers, for example apache. (In the package there
is an example with
apache).
The client side is look like an orinary application, all __remote
function is like extern.
The server side is more looks like as library, it must not have main.
C-wrapper compiler will generate all the needed code the client and server.
CRPC can be compiled on Linux and FreeBSD. It needs only libc (and
POSIX Threads now
either). The parser system is uses is written only in C. I tried to do
it as fast as it was possible.
So CRPC is something like a C extension, which I think will be more effective if
it will be a part of the C compiler.
One more difference is that CRPC can easily 'refactor' an existing
non-network application.
You only need to add __remote modificators to function prototypes and
recompile the source
and will get network application.
Also I am working the the threaded functions, mutual variables (POSIX
Threads support).
Have plans to add crypto support based on something like ssh.
/*
* Copyright (c) 2006-2008 by Andrey V. Babanin .
* All rights reserved.
*
* Please see COPYRIGHT.
*
* $Id: clnt.c,v 1.4 2008/02/06 17:13:22 granica_raydom Exp $
*/
#include
#include
#include
void __remote init_task(void);
__remote void checkto (double data[3]);
__remote short signed int
perform_task(unsigned int __in *mode,
unsigned int __out *data,int s)
__attribute((__format_ptr(0[2],1[2])));
__remote double check(unsigned int *);
__remote unsigned int mul(unsigned int lim);
int __remote _av(char **a,int n)
__attribute__((__format_ptr(0[1])));
int __remote _req(char *a);
void __remote _req2(char __in *sreq);
int __remote _req3(char __out sreq[100]);
int __remote _req4(char sreq[50]);
int main(int argc,char **argv) {
unsigned int mode[2]={1,3}, data[2]={0,0};
signed short int s;
int i;
unsigned int p=231;
double q=0;
double d[3]={2,4,1};
char a[]="98765";
char rr[100];
strcpy(rr,"POP1234567890");
i=_req4(rr);
printf("%s\n",rr);
bzero(rr,100);
i=_req3(rr);
printf("%s\n",rr);
_req2(a);
i=_req(a);
printf("%d\n",i);
i=_av(argv,argc);
printf("%d\n",i);
printf("%.2f %.2f %.2f\n",d[0],d[1],d[2]);
checkto(d);
printf("%.2f %.2f %.2f\n",d[0],d[1],d[2]);
init_task();
for(i=0;i<2;i++) {
data[0]=0;data[1]=0;
printf("%lu %lu %lu %lu\n",mode[0],mode[1],data[0],data[1]);
s=perform_task(mode,data,2);
printf("%lu %lu %lu %lu %d\n",mode[0],mode[1],data[0],data[1],s);
}
i=_av(argv,argc);
printf("%d\n",i);
q=check(&p);
printf("%.2lf\n",q);
unsigned long rm;
//rm=mul(1);
//printf("%lu\n",rm);
i=_av(argv,argc);
printf("%d\n",i);
return 0;
}
/*
* Copyright (c) 2006-2008 by Andrey V. Babanin .
* All rights reserved.
*
* Please see COPYRIGHT.
*
* $Id: serv.c,v 1.4 2008/02/06 17:13:22 granica_raydom Exp $
*/
#include
#include
#include
#include
static int scnt;
static int zz=0;
static __mutual int nm;
static __ptmutual_C1 int nm1;
static __ptmutual_C1 int nm2;
void __local checkto(double data[3]);
void __local init_task(void);
int __threaded p_init(double p);
short __local signed int
perform_task(unsigned int __in *mode,unsigned int __out *data, int n);
double __local check(unsigned int *);
__local __threaded unsigned int mul(unsigned int);
__local __threaded void sum(int
ARM interworking question
I have a question with regards to ARM interworking. The target is ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc, 4.3.1 with binutils maybe 3 months old. It seems that when interworking is enabled then when a piece of THUMB code calls an other piece of THUMB code in a separate file, it calls a linker-generated entry point that switches the CPU to ARM mode, then a jump is executed to an ARM prologue inserted in front of the target THUMB function that switches the CPU back into THUMB mode. That is, instead of a simple call, a call, a jump and two mode switches are executed. I also tried the -mcallee-super-interworking flag, which generates a short ARM to THUMB switching code in front of a THUMB function, but the final result does not seem to use the .real_entry_ofFUNCTIONNAME entry point. Rather, it goes through the same switch back and forth routine. Is there a way so when both the caller and the callee are compiled with interworking support the end code switching modes only when it is necessary? For example, placing a THUMB -> ARM prologue in front of all functions that are in ARM mode and ARM -> THUMB prologue in front of THUMB functions and the caller simply calling the real function or the prologue, depending on its own mode and that of the target? It would save both code space and execution time. Thanks, Zoltan
Re: ARM interworking question
Zoltán Kócsi wrote: > I have a question with regards to ARM interworking. The target is > ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc, > 4.3.1 with binutils maybe 3 months old. > > It seems that when interworking is enabled then when a piece of THUMB > code calls an other piece of THUMB code in a separate file, it calls > a linker-generated entry point that switches the CPU to ARM mode, then > a jump is executed to an ARM prologue inserted in front of the > target THUMB function that switches the CPU back into THUMB mode. That > is, instead of a simple call, a call, a jump and two mode switches are > executed. > > I also tried the -mcallee-super-interworking flag, which generates a > short ARM to THUMB switching code in front of a THUMB function, but the > final result does not seem to use the .real_entry_ofFUNCTIONNAME entry > point. Rather, it goes through the same switch back and forth routine. > > Is there a way so when both the caller and the callee are compiled with > interworking support the end code switching modes only when it is > necessary? For example, placing a THUMB -> ARM prologue in front of all > functions that are in ARM mode and ARM -> THUMB prologue in front of > THUMB functions and the caller simply calling the real function or the > prologue, depending on its own mode and that of the target? It would > save both code space and execution time. I don't get it. How would this work? When you have a function pointer you don't know if the target is thumb or ARM code, so how do you know where to jump to? Perhaps you could sketch out an implementation. Andrew.
Re: ARM interworking question
This message is really off topic for this list, please direct any follow-ups to gcc-h...@gcc.gnu.org. On Wed, 2009-01-21 at 19:53 +1100, Zoltán Kócsi wrote: > I have a question with regards to ARM interworking. The target is > ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc, > 4.3.1 with binutils maybe 3 months old. Unless you are working on legacy code (and it doesn't sound like it), you should be using the arm-eabi configuration now, rather than arm-elf. > It seems that when interworking is enabled then when a piece of THUMB > code calls an other piece of THUMB code in a separate file, it calls > a linker-generated entry point that switches the CPU to ARM mode, then > a jump is executed to an ARM prologue inserted in front of the > target THUMB function that switches the CPU back into THUMB mode. That > is, instead of a simple call, a call, a jump and two mode switches are > executed. > No, this shouldn't be happening unless a) you are doing something wrong; b) the options you are supplying to the compiler/linker are suggesting some sort of stubs are necessary. Can you provide precise details of what you are doing. A testcase would be ideal. > I also tried the -mcallee-super-interworking flag, which generates a > short ARM to THUMB switching code in front of a THUMB function, but the > final result does not seem to use the .real_entry_ofFUNCTIONNAME entry > point. Rather, it goes through the same switch back and forth routine. > I would recommend NOT using that option. It's provided only for specific legacy cases where existing code has been built without interworking. There are cases which simply cannot be handled by the methods it uses. R.
DWARF register numbering discrepancy on SPARC between GCC and GDB
Hello,
Eric and I discovered a discrepancy in the DWARF register numbering
on SPARC for floating point registers. The problem is more visible
on SPARC 64-bit because they are used for parameter passing, whether
i0 is used on 32-bit SPARC. Consider for instance the following code:
volatile register float r asm("f0");
int foo(float f)
{
r = f;
}
At -O0 -g:
st %i0, [%fp+68]
ld [%fp+68], %f0
.byte 0x5 ! uleb128 0x5; (DIE (0xd2) DW_TAG_variable)
.ascii "r\0"! DW_AT_name
.byte 0x1 ! DW_AT_decl_file (t.c)
.byte 0x1 ! DW_AT_decl_line
.uaword 0xdf! DW_AT_type
.byte 0x1 ! DW_AT_external
.byte 0x2 ! DW_AT_location
.byte 0x90! DW_OP_regx
!!-> .byte 0x28! uleb128 0x28
.byte 0x6 ! uleb128 0x6; (DIE (0xdf) DW_TAG_volatile_type)
.uaword 0xc9! DW_AT_type
As you can see, GCC tells us that variable "r" is in register 0x28=40.
The problem is that GCC thinks that register 40 is f0, whereas GDB
thinks that register 32 is f0.
More generally, GCC thinks that registers f0-f31 should be numbered 40-71:
/* Define how the SPARC registers should be numbered for Dwarf output.
The numbering provided here should be compatible with the native
svr4 SDB debugger in the SPARC/svr4 reference port. The numbering
is as follows:
Assembly namegcc internal regno Dwarf regno
--
g0-g70-7 0-7
o0-o78-158-15
l0-l716-23 16-23
i0-i724-31 24-31
f0-f31 32-63 40-71
According to Eric, this has been like that for the past since 1992.
However, when I tried to find some kind of official document
to confirm this numbering, I only found:
http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering
This is a wiki page, so I'm not sure how much we can trust the contents.
However, it does contradict the numbers above: Apparently DBX expects
f0-f31 to be numbered 32-63, not 40-71. If that information is correct,
perhaps Sun changed it since the first implementation in SDB? Does
anyone have maybe a more affirmative document?
The decision we need to make is to decide whether to change GDB
to match GCC or to change GCC. Changing GDB shouldn't be very hard,
but I think we should choose the same numbering scheme as DBX.
Opinions?
Thank you!
--
Joel
Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
Joel Brobecker writes: > However, when I tried to find some kind of official document > to confirm this numbering, I only found: > > http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering > > This is a wiki page, so I'm not sure how much we can trust the contents. > However, it does contradict the numbers above: Apparently DBX expects > f0-f31 to be numbered 32-63, not 40-71. If that information is correct, > perhaps Sun changed it since the first implementation in SDB? Does > anyone have maybe a more affirmative document? I'd suggest asking on tools-compil...@opensolaris.org where several Sun compiler developers hang around. An alternative is the Sun Studio Tools Forums at http://forums.sun.com/forum.jspa?forumID=852 although I find that forum stuff inconvenient to use compared to true mailing lists. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
> Date: Wed, 21 Jan 2009 15:08:47 +0400
>
> Hello,
>
> Eric and I discovered a discrepancy in the DWARF register numbering
> on SPARC for floating point registers. The problem is more visible
> on SPARC 64-bit because they are used for parameter passing, whether
> i0 is used on 32-bit SPARC. Consider for instance the following code:
>
> volatile register float r asm("f0");
>
> int foo(float f)
> {
> r = f;
> }
>
> At -O0 -g:
>
> st %i0, [%fp+68]
> ld [%fp+68], %f0
>
> .byte 0x5 ! uleb128 0x5; (DIE (0xd2) DW_TAG_variable)
> .ascii "r\0"! DW_AT_name
> .byte 0x1 ! DW_AT_decl_file (t.c)
> .byte 0x1 ! DW_AT_decl_line
> .uaword 0xdf! DW_AT_type
> .byte 0x1 ! DW_AT_external
> .byte 0x2 ! DW_AT_location
> .byte 0x90! DW_OP_regx
> !!-> .byte 0x28! uleb128 0x28
> .byte 0x6 ! uleb128 0x6; (DIE (0xdf) DW_TAG_volatile_type)
> .uaword 0xc9! DW_AT_type
>
> As you can see, GCC tells us that variable "r" is in register 0x28=40.
> The problem is that GCC thinks that register 40 is f0, whereas GDB
> thinks that register 32 is f0.
Strange, since the GCC 3.2 installed on one of the Solaris boxes at
work defenitely starts numbering from 32.
> More generally, GCC thinks that registers f0-f31 should be numbered 40-71:
>
> /* Define how the SPARC registers should be numbered for Dwarf output.
>The numbering provided here should be compatible with the native
>svr4 SDB debugger in the SPARC/svr4 reference port. The numbering
>is as follows:
>
>Assembly namegcc internal regno Dwarf regno
>--
>g0-g70-7 0-7
>o0-o78-158-15
>l0-l716-23 16-23
>i0-i724-31 24-31
>f0-f31 32-63 40-71
>
> According to Eric, this has been like that for the past since 1992.
Ah, but he is overlooking that sol2.h used to have its own defenition
of DBX_REGISTER_NUMBER:
/* However it appears that Solaris 2.0 uses the same reg numbering as
the old BSD-style system did. */
/* Same as sparc.h */
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(REGNO) \
(TARGET_FLAT && (REGNO) == HARD_FRAME_POINTER_REGNUM ? 31 : REGNO)
> However, when I tried to find some kind of official document
> to confirm this numbering, I only found:
>
> http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering
>
> This is a wiki page, so I'm not sure how much we can trust the contents.
> However, it does contradict the numbers above: Apparently DBX expects
> f0-f31 to be numbered 32-63, not 40-71. If that information is correct,
> perhaps Sun changed it since the first implementation in SDB? Does
> anyone have maybe a more affirmative document?
>
> The decision we need to make is to decide whether to change GDB
> to match GCC or to change GCC. Changing GDB shouldn't be very hard,
> but I think we should choose the same numbering scheme as DBX.
>
> Opinions?
Obviously the GCC folks broke backwards compatibility with themselves.
So unless we find evidence that contradicts the wiki page you cite, I
think GCC needs to be fixed.
OpenBSD and Linux are fine; they use 32-63 to number f0-f31.
GCC Profile base optimizations using simulator profile
Hi, I just wanted to see if there are others out there who get profile information from a simulator and feed that information back for GCC's PBO, in the .gcda format. I had tried this on picoChip, by changing the instrumentation code in GCC for fprofile-arcs and got edge profile working quite well (but GCC 4.4 would not accept just edge profile). I have never attempted to try others (indirect call, value profile etc), but would like to know the results of anyone who might have tried. Thanks. Hari
Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
> Obviously the GCC folks broke backwards compatibility with themselves. > So unless we find evidence that contradicts the wiki page you cite, I > think GCC needs to be fixed. Yes, the SVR4 definition used to be masked by that of the sol2.h file on Solaris and is not anymore. But the SVR4 definition is the one used for the various BSD variants. > OpenBSD and Linux are fine; they use 32-63 to number f0-f31. Linux is fine, OpenBSD is not, at least in the FSF tree. -- Eric Botcazou
Re: C integrated RPC
andrew babanin writes: > In attach you can find example program, > client and server side. And doc for the system as README file. > The newest version of the sources can be downloaded from > crpc at sf dot net. Thanks. This does seem useful for some people. I would be interested in hearing thoughts from other gcc maintainers. You say that the compiler is a wrapper around gcc, and there are various other tools as well. I don't see any reason that those other tools should be packaged with gcc; gcc is only a compiler, and people who need other tools can find them. What support needs to be in gcc proper? You mention that this works for GNU/Linux and FreeBSD, but of course gcc works for many more systems, including Windows and various embedded systems. You say it needs only libc, but of course it needs more than the ISO C library functions. Is the code written in a way that makes it easy to port to other systems? Ian
[target.md]: Backend passes cause code bloat of +140%.
Hi,
I am trying to write some simple builtin functions for target avr.
The buitins themselves are no proplem. The expansion works as intended.
What is unacceptable is a code bloat of +100% ... +150% during the RTL
passes.
So can anyone assist me in writing down RTL that will yield best/acceptable
performance?
The background is this:
AVR is an 8 bit Harvard Architecture with fairly limited resources,
i.e. some kByte of flash memory that hold program code and constant
data to be loaded at runtime.
Constant data can be loaded into a GPR by one instruction
LPM (load program memory) that comes in two flavours:
LPM Rn, Z ; char Rn = *Z
LPM Rn, Z+; char Rn = *Z++
where Rn is class "r" and Z must be one specific 16 bit register,
a combination of 2 subsequent 8 bit registers. Z is call clobbered.
For tiny targets there is just a
LPM ; char R0 = *Z
with the two implicit registers Z as above and R0 a fixed reg.
Up to now, LPM is not implemented in the compiler because GCC does not
allow to add new target specific qualifiers like "flash".
Therefore, the LPM stuff is implemented on libc-level as inline asm
macros.
The disadvantage of inline asm is that GCC does not know what is
going on in LPM and can take advantage of LPM Rn, Z++ and reuse Z.
So I tried writing a builtin "__builtin_pgm_read_byte".
Suppose the following trivial C test source:
char u[4];
void u1_dir (unsigned char * q)
{
u[0] = __builtin_pgm_read_byte (q);
}
char * u2_ind (char *u, unsigned char * q)
{
*u++ = __builtin_pgm_read_byte (q++);
*u++ = __builtin_pgm_read_byte (q++);
return u;
}
Using -Os the first function compiles to:
u1_dir:
/* prologue: function */
/* frame size = 0 */
movw r30,r24 ; 2 *movhi/1[length = 1]
lpm r24, Z+ ; 7 lpmZ_postinc_1 [length = 1]
sts u,r24; 9 *movqi/3[length = 2]
/* epilogue start */
ret ; 20 return [length = 1]
Fore the next test function you will expect code like that:
u2_ind:
movw r26, r24; X = arg #1
movw r30, r22; Z = arg #2
; with Rn some GPR
lpm Rn, Z+ ; Rn = *Z++
st X+, Rn ; *X++ = Rn
lpm Rn, Z+ ; Rn = *Z++
st X+, Rn ; *X++ = Rn
movw r24, r26; return = X
ret
However, the resulting code is unacceptable both from program memory
and from execution time wasted:
u2_ind:
push r28 ; 34 *pushqi/1 [length = 1]
push r29 ; 35 *pushqi/1 [length = 1]
/* prologue: function */The patch used UNSPEC in order to keep changes in the
backend minimal
/* frame size = 0 */
movw r26,r24 ; 2 *movhi/1[length = 1]
movw r30,r22 ; 7 *movhi/1[length = 1]
lpm r24, Z+ ; 8 lpmZ_postinc_1 [length = 1]
movw r28,r26 ; 30 *movhi/1[length = 1]
st Y+,r24; 9 *movqi/3[length = 1]
movw r30,r22 ; 32 *movhi/1[length = 1]
adiw r30,1 ; 11 *addhi3/2 [length = 1]
lpm r24, Z+ ; 13 lpmZ_postinc_1 [length = 1]
adiw r26,1 ; 14 *movqi/3[length = 3]
st X,r24
sbiw r26,1
movw r24,r28 ; 33 *movhi/1[length = 1]
adiw r24,1 ; 20 *addhi3/2 [length = 1]
/* epilogue start */
pop r29 ; 38 popqi [length = 1]
pop r28 ; 39 popqi [length = 1]
ret ; 40 return_from_epilogue[length = 1]
Not to imagine the impact on a real world application's performace.
What is going wrong?
I tried playing around with various RTL representations of LPM.
I also tried various command line switches like
-O2
-Os
-fno-split-wide-types
-fno-tree-scev-cprop
a.s.o.
Can anyoune give me some hints and teach me how to write the RTL
correctly?
I do not intend to mess around with a newly introduced pointer mode
like PHImode. Or would this bring the break through by avoiding
UNSPEC?
The patch is against 143546.
Regards, Georg-Johann
avr-__builtin_pgm_read_byte.patch
Description: Binary data
Re: [target.md]: Backend passes cause code bloat of +140%.
On Wed, 21 Jan 2009, Georg-Johann Lay wrote: > Up to now, LPM is not implemented in the compiler because GCC does not > allow to add new target specific qualifiers like "flash". Note that work on ISO TR 18037 named address spaces is underway for GCC 4.5 (currently on named-addr-spaces-branch). So you may wish to move to using that for accessing memory with special properties. -- Joseph S. Myers jos...@codesourcery.com
RE: [target.md]: Backend passes cause code bloat of +140%.
> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Wednesday, January 21, 2009 10:05 AM > To: gcc@gcc.gnu.org > Subject: [target.md]: Backend passes cause code bloat of +140%. > > Hi, > > I am trying to write some simple builtin functions for target avr. > Hi Georg-Johann, Anatoly Sokolov and I already have a patch to add builtin function capabilities for the AVR. Could you send us your patches? Thanks, Eric Weddington
Re: C integrated RPC
> 2009/1/21 Ian Lance Taylor : > What support needs to be in gcc > proper? As my wrapper compiler do some job, that GCC does, so I thought, that it would be better to add CRPC support to GCC. Maybe using some kind of plugin. CRPC wrapper compiler has it own automata and reads all the C input. You can name it as specialized preprocessor. When I started this work I though, that RPC functionality supported by compiler is a very good idea. No need using external tools, no need to think about network functions and so on. So wrapper compiler is good solution, as you use only one program - extension compiler and main compiler in one. > You say it needs only libc, but of course it needs > more than the ISO C library functions. Is the code written in a way > that makes it easy to port to other systems? CRPC has two main parts - C-wrapper compiler and shared library. Compiler is implicitly written with libc functions and standart Unix system calls. At this point it can be ported to any platform, that supports C. Wrapper compiler is built on my own parser, it does not need Lex/Bison. Parser partially implemets C syntax - variable declarations, typedefs and function prototype declarations. Library is dependent only on libc whether there is no need in threading support. The system should work on any BSD-like system, I have tested on Darwin(Power-PC), and it was ok. Also system will work on 32-bit and 64-bit systems (tested on amd64). On Linux everything is ok. Port it on CygWin is not a big problem to.
Re: remaining new darwin regressions
On Jan 20, 2009, at 11:22 PM, Jack Howarth wrote: Are there any observations that you could make concerning the thread... http://gcc.gnu.org/ml/gcc/2009-01/msg00297.html Sure, in i386/darwin.h we have: /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) This selects the maximal alignment to be 128 (16-bytes), the testcase works for all alignments of 16-bytes or less. For more aligning, I think that MAX, should be just a MIN: /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MIN (STACK_BOUNDARY, ix86_preferred_stack_boundary) this way, the code actually matches the comment as well. Plus, this then more closely matches non-darwin x86 machines: /* Boundary (in *bits*) on which the stack pointer prefers to be aligned; the compiler cannot rely on having this alignment. */ #define PREFERRED_STACK_BOUNDARY ix86_preferred_stack_boundary GIve that a try and let me know if it works. Seems to have been caused by -r132332: r125695 | echristo | 2007-06-13 18:53:17 -0700 (Wed, 13 Jun 2007) | 5 lines 2007-06-13 Eric Christopher * config/i386/darwin.h (PREFERRED_STACK_BOUNDARY): Don't let the user set a value below STACK_BOUNDARY. No testcase, bad, plus, the code: Index: darwin.h === --- darwin.h(revision 125694) +++ darwin.h(revision 125695) @@ -75,6 +75,16 @@ #undef STACK_BOUNDARY #define STACK_BOUNDARY 128 +/* Since we'll never want a stack boundary less aligned than 128 bits + we need the extra work here otherwise bits of gcc get very grumpy + when we ask for lower alignment. We could just reject values less + than 128 bits for Darwin, but it's easier to up the alignment if + it's below the minimum. */ +#undef PREFERRED_STACK_BOUNDARY +#define PREFERRED_STACK_BOUNDARY (ix86_preferred_stack_boundary > 128 \ + ? ix86_preferred_stack_boundary \ + : 128) + /* We want -fPIC by default, unless we're using -static to compile for the kernel or some such. */ doesn't seem to match the comment, bad. When researching, we find: http://gcc.gnu.org/ml/gcc-bugs/2008-02/msg01394.html IMO, there is no need for extra paranoia in darwin.h and following defines should be removed: /* On Darwin, the stack is 128-bit aligned at the point of every call. Failure to ensure this will lead to a crash in the system libraries or dynamic loader. */ #undef STACK_BOUNDARY #define STACK_BOUNDARY 128 /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY (ix86_preferred_stack_boundary > 128 \ ? ix86_preferred_stack_boundary \ : 128) (Could someone with darwin bootstraps and regtest removal of these defines? Do we even have an example of a failure for latest 4.3 if these are not defined?) From the original email to patches: So, with the change to specify STACK_BOUNDARY to 128, bits of gcc get grumpy if we set the preferred stack boundary to less than that. Since a value less than 128 doesn't really make sense and erroring out (or warning) is less than friendly for no reason here I'm just making it a minimum. It also fixes a few testcases. Committed to mainline after testing on x86-darwin. -eric 2007-06-13 Eric Christopher * config/i386/darwin.h (PREFERRED_STACK_BOUNDARY): Don't let the user set a value below STACK_BOUNDARY.
Re: C integrated RPC
andrew babanin wrote: 2009/1/21 Ian Lance Taylor : You say it needs only libc, but of course it needs more than the ISO C library functions. Is the code written in a way that makes it easy to port to other systems? CRPC has two main parts - C-wrapper compiler and shared library. Compiler is implicitly written with libc functions and standart Unix system calls. At this point it can be ported to any platform, that supports C. Wrapper compiler is built on my own parser, it does not need Lex/Bison. Parser partially implemets C syntax - variable declarations, typedefs and function prototype declarations. Library is dependent only on libc whether there is no need in threading support. The system should work on any BSD-like system, I have tested on Darwin(Power-PC), and it was ok. Also system will work on 32-bit and 64-bit systems (tested on amd64). On Linux everything is ok. Port it on CygWin is not a big problem to. I think this would have been useful on at least one project in my history. :) Ian mentioned embedded systems in an earlier question and I am still unsure what you require of the OS in terms of services to work. Cygwin is very close to a "real UNIX" from a programming viewpoint. + What do you require of the threading support? + Network services? + filesystem? + etc RTEMS is a single process, multithreaded RTOS with a port of the FreeBSD TCP/IP stack. Do you think that would that be sufficient to run on? Have you build this cross yet? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: C integrated RPC
> 2009/1/21 Joel Sherrill : > I think this would have been useful on at least one project > in my history. :) > > Ian mentioned embedded systems in an earlier question > and I am still unsure what you require of the OS in terms > of services to work. Cygwin is very close to a "real UNIX" > from a programming viewpoint. > > + What do you require of the threading support? > + Network services? > + filesystem? > + etc Hello. To work wrapper-compiler requires only libc, you can see it in the source. Compiler input/output implemented using mmap system call, and the process of language extension is like filtering the source - reading from one place of image and writing to another place of memory image. So I think compiler can compiled on every platform. (The problem with CygWin is that, my compiler requires file metadata in one place, but dirent struct is different on Win platform, but it is not hard to reimplement). Threading support is only deal with POSIX threads. You can create __threaded functions and __mutual varibles, wрich will be automatically locked and unlocked, before addressing. CRPC has it's own network protocol, based on BSD sockets and implemented in CRPC library. It is very easy, no external servicies are needed, as compiler helps with distinguishing remote functions (using 32-bit checksum calculated from the prototype text). > RTEMS is a single process, multithreaded RTOS with > a port of the FreeBSD TCP/IP stack. Do you think that > would that be sufficient to run on? > I thing it will be sufficient to run on it, but I have not ever tested on this systems. I will try to test on it. Am I answered you questions?
Re: C integrated RPC
andrew babanin wrote: 2009/1/21 Joel Sherrill : I think this would have been useful on at least one project in my history. :) Ian mentioned embedded systems in an earlier question and I am still unsure what you require of the OS in terms of services to work. Cygwin is very close to a "real UNIX" from a programming viewpoint. + What do you require of the threading support? + Network services? + filesystem? + etc Hello. To work wrapper-compiler requires only libc, you can see it in the source. Compiler input/output implemented using mmap system call, and the process of language extension is like filtering the source - reading from one place of image and writing to another place of memory image. So I think compiler can compiled on every platform. (The problem with CygWin is that, my compiler requires file metadata in one place, but dirent struct is different on Win platform, but it is not hard to reimplement). Threading support is only deal with POSIX threads. You can create __threaded functions and __mutual varibles, wрich will be automatically locked and unlocked, before addressing. CRPC has it's own network protocol, based on BSD sockets and implemented in CRPC library. It is very easy, no external servicies are needed, as compiler helps with distinguishing remote functions (using 32-bit checksum calculated from the prototype text). Is the marshalling and encoding based upon anything standard? Does it support RPC's across heterogeneous hosts? RTEMS is a single process, multithreaded RTOS with a port of the FreeBSD TCP/IP stack. Do you think that would that be sufficient to run on? I thing it will be sufficient to run on it, but I have not ever tested on this systems. I will try to test on it. Am I answered you questions? I think so. The run-time assumes POSIX threads and BSD sockets and (I assume) POSIX mutex for the locking. Depending on how things go with the merge, it probably makes sense to switch to the gcc portability wrappers for threading and mutexes. But it is up to others on merging. I was just trying to clarify the run-time requirements. :) Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: remaining new darwin regressions
Hello! Sure, in i386/darwin.h we have: /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) This selects the maximal alignment to be 128 (16-bytes), the testcase works for all alignments of 16-bytes or less. For more aligning, I think that MAX, should be just a MIN: Er, no. MAX(X,Y) macro selects the higher of two values, i.e.: #define MIN(X,Y) ((X) < (Y) ? (X) : (Y)) #define MAX(X,Y) ((X) > (Y) ? (X) : (Y)) (The definition is in system.h). So, we never go below 128. Uros.
Re: remaining new darwin regressions
On Jan 21, 2009, at 11:40 AM, Uros Bizjak wrote: Hello! Sure, in i386/darwin.h we have: /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) This selects the maximal alignment to be 128 (16-bytes), the testcase works for all alignments of 16-bytes or less. For more aligning, I think that MAX, should be just a MIN: Er, no. MAX(X,Y) macro selects the higher of two values, i.e.: #define MIN(X,Y) ((X) < (Y) ? (X) : (Y)) #define MAX(X,Y) ((X) > (Y) ? (X) : (Y)) (The definition is in system.h). So, we never go below 128. Agreed. We cannot go below 128 bits on darwin. Any change that allows that to happen is incorrect. -eric
Re: C integrated RPC
>>> 2009/1/21 Joel Sherrill :
>
> Is the marshalling and encoding based upon anything
> standard?
>
> Does it support RPC's across heterogeneous hosts?
Data that should be send through the net is packed using my own method.
It is rather simple, but marshaling is made automatically, in C code, generated
by wrapper compiler. This data format supports so called __in and __out data,
so as the system (__in and __out midificators used with function paramters).
So the system can control which data should be send to the server and which
data should be retrived from the server.
CRPC can forward calls for remote functions, also remote calls can be
done from another
servers, like apache (from apache module). As it uses TCP/IP it will
work with heterogeneous
hosts.
>
> I think so. The run-time assumes POSIX threads and BSD sockets
> and (I assume) POSIX mutex for the locking.
But there might be some problems running treaded application yet) I am
working on it.
> Depending on how things go with the merge, it probably makes
> sense to switch to the gcc portability wrappers for threading
> and mutexes. But it is up to others on merging. I was just
> trying to clarify the run-time requirements. :)
>
To see how wrapper-compiles extends there is two files in attach, the source
and temporary compiler file after language extension.
/*
* Copyright (c) 2006-2008 by Andrey V. Babanin .
* All rights reserved.
*
* Please see COPYRIGHT.
*
* $Id: clnt.c,v 1.4 2008/02/06 17:13:22 granica_raydom Exp $
*/
#include
#include
#include
void __remote init_task(void);
__remote void checkto (double data[3]);
__remote short signed int
perform_task(long int __in *mode,long int __out *data,int s)
__attribute((__format_ptr(0[2],1[2])));
__remote double check(unsigned int *);
__remote unsigned long int mul(unsigned long int lim);
int __remote _av(char **a,int n)
__attribute__((__format_ptr(0[1])));
int main(int argc,char **argv) {
long int mode[2]={1,3}, data[2]={0,0};
signed short int s;
unsigned int p=231, i;
double q=0;
double d[3]={2,4,1};
i=_av(argv,argc);
printf("%d\n",i);
printf("%.2f %.2f %.2f\n",d[0],d[1],d[2]);
checkto(d);
printf("%.2f %.2f %.2f\n",d[0],d[1],d[2]);
init_task();
for(i=0;i<2;i++) {
data[0]=0;data[1]=0;
printf("%lu %lu %lu %lu\n",mode[0],mode[1],data[0],data[1]);
s=perform_task(mode,data,2);
printf("%lu %lu %lu %lu %d\n",mode[0],mode[1],data[0],data[1],s);
}
i=_av(argv,argc);
printf("%d\n",i);
q=check(&p);
printf("%.2lf\n",q);
unsigned long rm;
rm=mul(1);
printf("%lu\n",rm);
i=_av(argv,argc);
printf("%d\n",i);
return 0;
}
r6vShf.i
Description: Binary data
Re: remaining new darwin regressions
On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote: Sure, in i386/darwin.h we have: /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) This selects the maximal alignment to be 128 (16-bytes), the testcase works for all alignments of 16-bytes or less. For more aligning, I think that MAX, should be just a MIN: Er, no. Er, [ feeling stupid ] shucks. :-( I was thinking the problem was the instructions to do on demand alignment, fails to be generated in darwin, because darwin goes out of it's way to say, you don't need to do that (since we already have 128 aligned stacks), but that code fails to consider alignments greater than 128, thus causing the failure.
Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
From: Eric Botcazou Date: Wed, 21 Jan 2009 15:22:19 +0100 > > Obviously the GCC folks broke backwards compatibility with themselves. > > So unless we find evidence that contradicts the wiki page you cite, I > > think GCC needs to be fixed. > > Yes, the SVR4 definition used to be masked by that of the sol2.h file on > Solaris and is not anymore. But the SVR4 definition is the one used for > the various BSD variants. Ok, so it seems the fix is to reinstate the override in sol2.h, right?
Re: remaining new darwin regressions
On Wed, Jan 21, 2009 at 11:59:09AM -0800, Mike Stump wrote: > On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote: >>> Sure, in i386/darwin.h we have: >>> >>> /* Since we'll never want a stack boundary less aligned than 128 bits >>> we need the extra work here otherwise bits of gcc get very grumpy >>> when we ask for lower alignment. We could just reject values less >>> than 128 bits for Darwin, but it's easier to up the alignment if >>> it's below the minimum. */ >>> #undef PREFERRED_STACK_BOUNDARY >>> #define PREFERRED_STACK_BOUNDARY\ >>> MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) >>> >>> This selects the maximal alignment to be 128 (16-bytes), the >>> testcase works for all alignments of 16-bytes or less. For more >>> aligning, I think that MAX, should be just a MIN: >> >> Er, no. > > Er, [ feeling stupid ] shucks. :-( I was thinking the problem was the > instructions to do on demand alignment, fails to be generated in darwin, > because darwin goes out of it's way to say, you don't need to do that > (since we already have 128 aligned stacks), but that code fails to > consider alignments greater than 128, thus causing the failure. Mike, So that invalidates your previously proposed patch? Or should I still test it? Jack
Re: This is a Cygwin failure yeah?
2009/1/18 Dave Korn : > Andy Scott wrote: > >> Again stage3 part of build, and this is what actually stops the build >> the above issue doesn't seem to (I think it happens in stage 2), I get >> the following: >> >> > > < a few more lines of log deleted :) > > >> ../../../gcc/libiberty/strsignal.c -o strsignal.o >> ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for >> 'strsignal' >> /usr/include/string.h:78: note: previous declaration of 'strsignal' was here >> make[2]: *** [strsignal.o] Error 1 >> make[2]: Leaving directory >> `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' >> make[1]: *** [all-target-libiberty] Error 2 >> make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' >> make: *** [all] Error 2 > >Hi Andy, > > I created a bugzilla entry for the failure: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903 > > I've applied a patch to GCC SVN HEAD to fix the strsignal bug (r.143487), > and would appreciate if you could verify that it solves the build > failure for you. > >thanks, > DaveK > Dave Cheers for that. I will do when I get back to my machine tomorrow; been laid up since Sunday with the flu so only just seen this, so apologies for the late reply. Andy -- Brain upgrade required: a working hypothalamus
Re: [target.md]: Backend passes cause code bloat of +140%.
Weddington, Eric schrieb: Hi, I am trying to write some simple builtin functions for target avr. Hi Georg-Johann, Anatoly Sokolov and I already have a patch to add builtin function capabilities for the AVR. Could you send us your patches? Hi Eric, I just gave the builtin approch for pgm_read_stuff a try and played around with some RTL variants. The patch in my original post (how can I cite an email?) is all I have. It's just an builtin skeleton that adds a single builtin in avr.c and a handhull of useless insns. No comments. No documentation. I used svn diff to get the patch. Georg-Johann
cross-compilation and crt issues
Hi,
I am trying to generate a cross-compiler targetting ARM wince plateform
from gcc trunk and I have an error message
when compiling mingw and regarding linker
My tree is organized like this :
src
+ binutils
+ gcc
+ mingw
+ w32api
+ build-mingw32ce
and I am using a script to build the different modules in the following
order : binutils bootstrap-gcc mingw w32api gcc
> cd build-mingw32ce
../build-mingw32ce.sh -j2
build-mingw32ce.sh:
...
build_binutils()
{
echo ""
echo "BUILDING BINUTILS --"
echo ""
echo ""
mkdir -p binutils
cd binutils
${BASE_DIRECTORY}/binutils/configure \
--prefix=${PREFIX} \
--target=${TARGET} \
--disable-nls
make ${PARALLELISM}
make install
cd ${BUILD_DIR}
}
build_bootstrap_gcc()
{
mkdir -p gcc-bootstrap
cd gcc-bootstrap
${BASE_DIRECTORY}/${gcc_src}/configure \
--with-gcc \
--with-gnu-ld \
--with-gnu-as \
--target=${TARGET} \
--prefix=${PREFIX} \
--disable-threads \
--disable-nls \
--enable-languages=c \
--disable-win32-registry \
--disable-multilib \
--disable-shared \
--disable-interwork\
--without-newlib \
--enable-checking
make ${PARALLELISM} all-gcc
make install-gcc
cd ${BUILD_DIR}
}
build_mingw()
{
mkdir -p mingw
cd mingw
${BASE_DIRECTORY}/mingw/configure \
--build=${BUILD} \
--host=${TARGET} \
--target=${TARGET}\
--prefix=${PREFIX}
make ${PARALLELISM}
make install
cd ${BUILD_DIR}
}
...
The problem I have is about crtstuff in mingw :
source: /home/Vincent/cegcc-4.4.0/src
building in: /home/Vincent/cegcc-4.4.0/src/build-mingw32ce
prefix: /opt/mingw32ce
components: mingw
checking package version... 3.11
checking build system type... i686-pc-cygwin
checking host system type... arm-unknown-mingw32ce
checking target system type... arm-unknown-mingw32ce
checking for arm-mingw32ce-gcc... arm-mingw32ce-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-mingw32ce-gcc accepts -g... yes
checking for arm-mingw32ce-gcc option to accept ANSI C... none needed
checking for arm-mingw32ce-ar... arm-mingw32ce-ar
checking for arm-mingw32ce-as... arm-mingw32ce-as
checking for arm-mingw32ce-ranlib... arm-mingw32ce-ranlib
checking for arm-mingw32ce-ld... arm-mingw32ce-ld
checking for arm-mingw32ce-dlltool... arm-mingw32ce-dlltool
checking for arm-mingw32ce-dlltool... arm-mingw32ce-dlltool
checking for arm-mingw32ce-windres... arm-mingw32ce-windres
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
configure: configuring in mingwex
configure: running /bin/sh
'/home/Vincent/cegcc-4.4.0/src/mingw/mingwex/configure'
--prefix=/opt/mingw32ce '--build=i686-pc-cygwin' '--host=arm-mingw32ce'
'--target=arm-mingw32ce' '--prefix=/opt/mingw32ce'
'build_alias=i686-pc-cygwin' 'host_alias=arm-mingw32ce'
'target_alias=arm-mingw32ce' --cache-file=/dev/null
--srcdir=/home/Vincent/cegcc-4.4.0/src/mingw/mingwex
checking build system type... i686-pc-cygwin
checking host system type... arm-unknown-mingw32ce
checking target system type... arm-unknown-mingw32ce
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
Making in mingwex...
make[1]: Entering directory
`/home/Vincent/cegcc-4.4.0/src/build-mingw32ce/mingw/mingwex'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/home/Vincent/cegcc-4.4.0/src/build-mingw32ce/mingw/mingwex'
arm-mingw32ce-dlltool --as arm-mingw32ce-as --output-def mingwthrd.def
mthr.o mthr_init.o
arm-mingw32ce-dlltool --as arm-mingw32ce-as --output-def mingwthrd.def
mthr.o mthr_init.o
arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll
-Wl,--image-base,0x6FBC mthr.o mthr_init.o -Lmingwex \
-o mingwthrd_dummy.exe
arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll
-Wl,--image-base,0x6FBC mthr.o mthr_init.o -Lmingwex \
-o mingwthrd_dummy.exe
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make: *** [mingwthrd.def] Error 1
make: *** Waiting for unfinished jobs
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make: *** [mingwm10.dll] Error 1
Could someone tell me if gcc-4.4 needs more parameters when cross-compiling
because it works fine with g
Re: [target.md]: Backend passes cause code bloat of +140%.
Joseph S. Myers schrieb: On Wed, 21 Jan 2009, Georg-Johann Lay wrote: Up to now, LPM is not implemented in the compiler because GCC does not allow to add new target specific qualifiers like "flash". Note that work on ISO TR 18037 named address spaces is underway for GCC 4.5 (currently on named-addr-spaces-branch). So you may wish to move to using that for accessing memory with special properties. Ok, thanks for that hint. Besides that, can you say why my patch makes the compiled target code explode? What's wrong with my insns and expanders? It is not the first time that I observe very bad code and superfluous insns and reloads playing around and givin some optimisations a try. Georg-Johann
Re: remaining new darwin regressions
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote: So that invalidates your previously proposed patch? Or should I still test it? No need to test, I was wrong about that being the bit that causes it. The description I last posted should be about right however, one just needs a bit of time in the debugger to find it (and the thing that controls it).
gcc-4.2-20090121 is now available
Snapshot gcc-4.2-20090121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090121/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 143556 You'll find: gcc-4.2-20090121.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090121.tar.bz2 C front end and core compiler gcc-ada-4.2-20090121.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090121.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090121.tar.bz2 C++ front end and runtime gcc-java-4.2-20090121.tar.bz2 Java front end and runtime gcc-objc-4.2-20090121.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090121.tar.bz2The GCC testsuite Diffs from 4.2-20090114 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: [target.md]: Backend passes cause code bloat of +140%.
Weddington, Eric schrieb:
> Anatoly Sokolov and I already have a patch to add builtin function
capabilities for the AVR. Could you send us your patches?
The patch is contained in my top post
http://gcc.gnu.org/ml/gcc/2009-01/msg00309.html
Here a verbatim copy, so it is easier to discuss what goes wrong and how
things could have been implemented better.
It's nice to learn about gcc no matter if the stuff below will end in
gcc or not.
Georg-Johann
Index: gcc/config/avr/avr.md
===
--- gcc/config/avr/avr.md(revision 143546)
+++ gcc/config/avr/avr.md(working copy)
@@ -59,7 +59,10 @@
(UNSPECV_EPILOGUE_RESTORES1)
(UNSPECV_WRITE_SP_IRQ_ON2)
(UNSPECV_WRITE_SP_IRQ_OFF3)
- (UNSPECV_GOTO_RECEIVER4)])
+ (UNSPECV_GOTO_RECEIVER4)
+
+ (UNSPEC_LPM 10)
+ ])
(include "predicates.md")
(include "constraints.md")
@@ -3262,3 +3265,102 @@
expand_epilogue ();
DONE;
}")
+
+
+(define_expand "pgm_read_byte"
+ [(parallel[(match_operand:QI 0 "register_operand" "")
+ (match_operand:HI 1 "register_operand" "")])]
+ ""
+ {
+ rtx Z = gen_rtx_REG (HImode, REG_Z);
+rtx reg_z = gen_reg_rtx (HImode);
+rtx reg_z1 = gen_reg_rtx (HImode);
+
+switch (avr_test)
+{
+case 0:
+emit_move_insn (Z, operands[1]);
+emit_insn (gen_lpmZ_postinc (operands[0]));
+break;
+
+case 1:
+emit_move_insn (Z, operands[1]);
+emit_insn (gen_lpmZ_postinc_1 (operands[0]));
+break;
+
+case 2:
+/* Allow modified Z to have other pseudo number than Z */
+emit_move_insn (Z, operands[1]);
+emit_insn (gen_lpmZ_postinc_2 (operands[0], reg_z1));
+break;
+
+case 3:
+/* Allow modified Z to have other pseudo number than Z */
+emit_move_insn (reg_z, operands[1]);
+emit_insn (gen_lpmZ_postinc_3 (operands[0], reg_z1,
reg_z));
+break;
+
+default: abort();
+}
+
+DONE;
+ })
+
+;; %0 = *Z
+(define_insn "lpmZ"
+ [(set (match_operand:QI 0 "register_operand" "=r")
+(unspec:QI [(mem:QI (reg:HI REG_Z))
+] UNSPEC_LPM))]
+ ""
+ "lpm %0, Z"
+ [(set_attr "cc" "none")
+ (set_attr "length" "1")])
+
+;; %0 = *Z++
+(define_insn "lpmZ_postinc"
+ [(set (reg:HI REG_Z)
+(plus:HI (reg:HI REG_Z)
+ (const_int 1)))
+ (set (match_operand:QI 0 "register_operand" "=r")
+ (unspec:QI [(mem:QI (reg:HI REG_Z))
+ ] UNSPEC_LPM))]
+ ""
+ "lpm %0, Z+"
+ [(set_attr "cc" "none")
+ (set_attr "length" "1")])
+
+
+(define_insn "lpmZ_postinc_1"
+ [(set (match_operand:QI 0 "register_operand" "=r")
+(unspec:QI [(mem:QI (post_inc (reg:HI REG_Z)))
+ ] UNSPEC_LPM))]
+ ""
+ "lpm %0, Z+"
+ [(set_attr "cc" "none")
+ (set_attr "length" "1")])
+
+(define_insn "lpmZ_postinc_2"
+ [(set (match_operand:HI 1 "register_operand" "+z")
+(plus:HI (reg:HI REG_Z)
+ (const_int 1)))
+
+ (set (match_operand:QI 0 "register_operand" "=r")
+(unspec:QI [(mem:QI (reg:HI REG_Z))
+] UNSPEC_LPM))]
+ ""
+ "lpm %0, Z+"
+ [(set_attr "cc" "none")
+ (set_attr "length" "1")])
+
+(define_insn "lpmZ_postinc_3"
+ [(set (match_operand:HI 1 "register_operand" "=z")
+(plus:HI (match_operand:HI 2 "register_operand" "z")
+ (const_int 1)))
+
+ (set (match_operand:QI 0 "register_operand" "=r")
+(unspec:QI [(mem:QI (match_dup 2))
+] UNSPEC_LPM))]
+ ""
+ "lpm %0, Z+"
+ [(set_attr "cc" "none")
+ (set_attr "length" "1")])
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c(revision 143546)
+++ gcc/config/avr/avr.c(working copy)
@@ -29,6 +29,7 @@
#include "real.h"
#include "insn-config.h"
#include "conditions.h"
+#include "insn-codes.h"
#include "insn-attr.h"
#include "flags.h"
#include "reload.h"
@@ -45,6 +46,8 @@
#include "target-def.h"
#include "params.h"
#include "df.h"
+#include "langhooks.h"
+#include "optabs.h"/* For GEN_FCN */
/* Maximal allowed offset for an address in the LD command */
#define MAX_LD_OFFSET(MODE) (64 - (signed)GET_MODE_SIZE (MODE))
@@ -88,6 +91,9 @@ static struct machine_function * avr_ini
static rtx avr_builtin_setjmp_frame_value (void);
static bool avr_hard_regno_scratch_ok (unsigned int);
+static void avr_init_builtins_hook (void);
+static rtx avr_expand_builtin_hook (tree, rtx, rtx, enum machine_mode
mode, int);
+
/* Allocate registers from r25 to r8 for parameters for function
calls. */
#define FIRST_CUM_REG 26
@@ -357,6 +363,12 @@ int avr_case_values_threshold = 3;
#undef TARGET_HARD_REGNO_SCRATCH_OK
#define TA
Size of the GCC repository
Hi, for the record, today I started an rsync to get a local copy of the repository and, at variance with the information in: http://gcc.gnu.org/rsync.html the size I'm seeing is already > 17G, and counting... If somebody knows the total size and wants to update the web page, I think it would be a nice idea, otherwise I will take care of that... when it finishes... ;) Paolo.
Re: Size of the GCC repository
17,327,572 k :) On Wed, Jan 21, 2009 at 8:13 PM, Paolo Carlini wrote: > Hi, > > for the record, today I started an rsync to get a local copy of the > repository and, at variance with the information in: > > http://gcc.gnu.org/rsync.html > > the size I'm seeing is already > 17G, and counting... If somebody knows > the total size and wants to update the web page, I think it would be a > nice idea, otherwise I will take care of that... when it finishes... ;) > > Paolo. >
He's short but with such an instrument. handy
http://www.google.com/group/assureinaldoingram?auzlmvvrjthusst resort rests Twice By-the-way collapsed bath-sponge fulfillment field caps
