RE: Lattice Mico32 port
> The port is ok to check in. Great - so can I apply it, or does someone else need to? Cheers, Jon
How to support 40bit GP register
HI all,
I am porting GCC 4.4.0 for a 32bit target. The target has 40bit data
registers and 32bit address registers that can be used as general
purpose registers. When 40bit registers are used for arithmetic
operations or comparison operations GCC generates code assuming that
its a 32bit register. Whenever there is a move from address register
to data register sign extension is automatically performed by the
target. Since the data register is 40bit after some operations
sign/zero extension has to be performed for the result to be proper.
Take the following test case for example :
typedef struct
{
char b0;
char b1;
char b2;
char b3;
char b4;
char b5;
} __attribute__ ((packed)) b_struct;
typedef struct
{
short a;
long b;
short c;
short d;
b_struct e;
} __attribute__ ((packed)) a_struct;
int
main(void)
{
volatile a_struct *a;
volatile a_struct b;
a = &b;
*a = (a_struct){1,2,3,4};
a->e.b4 = 'c';
if (a->b != 2)
abort ();
exit (0);
}
For accessing a->b GCC generates the following code:
move.l (sp-16), d3
lsrr.l #<16, d3
move.l (sp-12),d2
asll#<16,d2
or d3,d2
cmpeq.w #<2,d2
jf _L2
Because data registers are 40 bit for 'asll' operation the shift count
should be 16+8 or there should be sign extension from 32bit to 40 bits
after the 'or' operation. The target has instruction to sign extend
from 32bit to 40 bit.
Similarly there are other operation that requires sign/zero extension.
So is there any way to tell GCC that the data registers are 40bit and
there by expect it to generate sign/zero extension accordingly ?
Regards,
Shafi
gcc ld error
Hi, everyone:
I have ported the gcc, newlib and binutils to my new risc target.
But when I write a simple program helloworld.c:
#include
int main(void)
{
printf("Hello World!!!\n");
return 0;
}
run the command like this:
rice-elf-gcc helloworld.c
error occurred from ld which indicates some undefine reloc names.
I just wanna get the argment passed to ld, when I could debug the
ld with gdb.
I run the command the
rice-elf-gcc helloworld.c -v
But I couldn't get the parameter passed to ld.
and I don't know what the relationship between "collect2" and
"ld". It seems they do have some connections between them.
Thanks very much.
Best wishes.
daniel
Re: gcc ld error
daniel tian writes: > I just wanna get the argment passed to ld, when I could debug the > ld with gdb. > I run the command the > rice-elf-gcc helloworld.c -v > But I couldn't get the parameter passed to ld. > and I don't know what the relationship between "collect2" and > "ld". It seems they do have some connections between them. collect2 invokes ld with the same options (with a couple of unimportant exceptions) that were passed to collect2. To see precisely what collect2 does: rice-elf-gcc -v -Wl,-debug helloworld.c (The -debug option is one of the exceptions: collect2 does not pass it on to ld.) Ian
CFG,DFG
Hi.. The compiler stores the information about dependencies among various instruction in control flow graphs and data flow graph. What kind of graphs are these? and can this dependency information be extracted from gcc? Thanks Swati Raina Get your new Email address! Grab the Email name you've always wanted before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/
cloud_slon хочет читать вас в РуТвите
Добрый день! Ваш друг cloud_slon хочет стать вашим читателем на сайте RuTvit.ru. Чтобы начать пользоваться сайтом, нажмите на ссылку-приглашение https://rutvit.ru/register?invitecode=0cc43818a5e1e88bea063b3c8873b1ff7bfef8e2 Желаем удачи! РуТвит, пульс России
Re: How to support 40bit GP register
On 10/21/2009 07:25 AM, Mohamed Shafi wrote: For accessing a->b GCC generates the following code: move.l (sp-16), d3 lsrr.l #<16, d3 move.l (sp-12),d2 asll#<16,d2 or d3,d2 cmpeq.w #<2,d2 jf _L2 Because data registers are 40 bit for 'asll' operation the shift count should be 16+8 or there should be sign extension from 32bit to 40 bits after the 'or' operation. The target has instruction to sign extend from 32bit to 40 bit. Similarly there are other operation that requires sign/zero extension. So is there any way to tell GCC that the data registers are 40bit and there by expect it to generate sign/zero extension accordingly ? Define a machine mode for your 40-bit type in cpu-modes.def. Depending on how your 40-bit type is stored in memory, you'll use either INT_MODE (RI, 5)// load-store uses exactly 5 bytes FRACTIONAL_INT_MODE (RI, 40, 8) // load-store uses 8 bytes Where I've arbitrarily chosen "RImode" as a mnemonic for Register Integral Mode. Now you define arithmetic operations, as needed, on RImode. You define the "extendsiri" pattern to be that sign-extend from 32-to-40-bit instruction. You define your comparison patterns on RImode, and not on SImode, since your comparison instruction works on the entire 40 bits. You'll wind up with a selection of patterns in your machine description that have a sign-extension pattern built in, depending on the exact behaviour of your ISA. There are plenty of examples on x86_64, mips64, and Alpha (to name a few) that have similar properties with SI and DImodes. Examine the -fdump-rtl-combine-details dump for exemplars of the canonical forms that the combiner creates when it tries to merge sign-extension instructions into preceeding patterns. r~
Re: CFG,DFG
swati raina writes: > The compiler stores the information about dependencies among various > instruction in control flow graphs and data flow graph. What kind of > graphs are these? and can this dependency information be extracted > from gcc? See cfg*.[ch] and df*.[ch]. Note that df*.[ch] only applies to RTL. There is no clean way to extract the dependency information. Your best approach would be to write a plugin to dump the information in some useful format. Ian
Re: When did arc-elf last build?
On 10/19/2009 10:48 AM, Richard Guenther wrote: On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill wrote: Hi, I got a random unsolicited email about arc-elf since I pop up in google a lot asking cross compiler questions. I decided to try to build it and as PR41747 indicates 4.3.4, 4.4.1, and the head all fail building libgcc2.c in the same way. T I did a search for arc-elf in the test results mail list archives and found none. I found a thread (http://gcc.gnu.org/ml/gcc/2003-02/msg01595.html) where apparently I tried years ago to do the same thing and didn't have any luck. [Lucky for mail list archives since I didn't remember this at all. :D ] So I am asking.. is arc-elf in use by anyone? When did it last build? And there is no maintainer listed. Anybody out there care about it? :) If there is no maintainer listed for this port and it doesn't build I suggest to drop it for GCC 4.5. Same for m68hc11. Paolo
Dead Store Elimination
Hi, A possible silly question about the dead store elimination pass. From the documentation it is clear that the store S1 below is removed by this pass (in dse.c) *(addr) = value1; // S1 . . *(addr) = value2 // S2 .. No read of "addr" between S1 and S2. .. = *(addr) // Load ... end_of_the_function However, consider a different example. *(addr) = value1; // S1 .. . end_of_the_function. i.e. there is no store Sn that follows S1 along any path from S1 to the end of the function and there is no read of addr following S1 either. Is the dse pass expected to remove such stores ? (I am inclined to think that it should, but I am seeing a case where dse doesnt remove such stores) . Further is the behaviour expected to be different if the "addr" is based on "fp" ? TIA, Pranav
Re: CFG,DFG
On 10/22/2009 01:57 AM, Ian Lance Taylor wrote: See cfg*.[ch] and df*.[ch]. Note that df*.[ch] only applies to RTL. There is no clean way to extract the dependency information. On trees, the SSA def-use edges could be seen as (well, are) a DFG. Paolo
Re: i370 port - constructing compile script
Hi Ulrich. I've had considerable success in this process. I've now reached the point where I seem to have a correctly generated config.h in libiberty and correct auto-host.h in gcc, which is one of the aims in order to get an eventual link on MVS. However, it meant that I could look at the auto-host.h and see what it had come up with. It correctly figured out that I didn't have a raft of header files, but still thought I had lots of functions like fork() and getrusage(). I suspect that is because my fake compiler is compiling with the "-S' option and returning success when it's after a link failure. OK. I thought with the fake as and ld scripts, you should no longer need a "fake compiler" script? I haven't got to the stage of playing around with that yet. But even so, you're right that the "fake linker" will not actually check whether symbols are present in your library ... I had an idea - maybe I can have warnings switched on for functions without prototypes, and then my dummy compiler trap the output and do a "wc" and if there's an unexpectedly high number of lines, then it can exit with failure. Or simply use -Werror when doing test compiles in configure. Turns out that -Werror-implicit-function-declaration wasn't sufficient. Because "configure" dutifully goes and inserts its own declaration for the non-existant functions! However, more intrusive code: + #if !defined(__MVS__) char $ac_func (); + #else + #include + #include + #include + #include + #include + #include + #endif got past that problem, such that I could get the config file I needed. I needed to put in the standard includes, otherwise it thought that I didn't even have memcmp! Any suggestion on how to make this less intrusive? Or perhaps is it logical to have a generic "trap at compile time instead of link time" configure option for other environments also? Maybe we could have two variables, a BEFORE_AC_FUNC and AFTER_AC_FUNC which are defined in all those tests, and can be set to open comment and close comment + includes to achieve the above effect. Or maybe I should simply pass over the configure script doing that substitution, since the string to search for is unique and consistent, ie grep "^char \$ac_func" configure char $ac_func (); /* The GNU C library define to always fail with ENO something starting with #if defined (__stub_$ac_fun choke me #else char (*f) () = $ac_func; I was thinking that maybe what I should do is in the fake linker, see what the output executable is. If the output executable is a conftest, then do a scan of the VCONs (external references) in the assembler making sure they are all C90. But that seems to be the wrong approach to me. If there's going to be a list of C90 functions and variables it should probably be in configure.ac I think. Speaking of which. When I was putting in the intrusive code, I saw things like newlib and Vxworks which had explicit mention and explicit settings for various things. Perhaps I should be doing something like that too rather than faking things to get them through? That would lower the barrier for an arbitrary and possibly complicated target with no extensions. However, let's stay on the current track, so that e.g. this could be used to target mvsdignus, which probably does have various extensions, and they may wish to make use of them in their MVS build. Thus, it needs to go through the detection process. Assuming that detection process has worked, and the config.h file is correctly set, then I run into the next problem. A stack of C files in libiberty failed to compile, because they have extensions in them. E.g. make-temp-file.c calls access(). I've never noticed them before because I've never included them in my links, because they are not required on MVS. Even totally unrelated things like pex-unix.c are being compiled. So what is the best way of switching the source code to compile? It is at this stage that I wish to create a single executable, so would want the fake linker to do a tar or zip. (or simply an echo, I'm flexible on that). So those failing files would presumably be omitted from that anyway? Or are they normally unconditionally compiled and linked? Finally, even with this in place, the build process stopped at the next roadblock. The file "genmodes.c" couldn't be compiled. I was surprised to see that it was being compiled with i370-mvspdp-gcc. The genmodes "needs" to be run on Unix still. It's only the source code that IT generates that needs to be cross-compiled. Regardless, genmodes.c didn't compile because auto-build.h correctly detected that my Unix system has etc, but my own header files don't have that, so a cross compile doesn't work. How does that normally work when cross-compiling a host? BTW, I really like the idea of the fake linker zipping up all the generated assembler as it goes through, which is ultimately what I need to send up to MVS. The JCL can be generated from "unzip -v" a
