An assortment of questions
Hello. This is my first post to this list, so I apologise in advance if I get any of the 'stupid newbie' things wrong in this post. I have spent a while reading the last month's archive. I'm looking at the need to build a very comprehensive code optimizer and generator for a very strange (antique but still used mainframe) machine. Since I'm really and OS type and in a rational world would never be attempting compiler stuff, I figure I'm better off starting with the work of others and extending it rather than making foolish attempts t start from scratch. The GCC chain looks like a particularly good starting place. There are several things I'll need to do that it doesn't appear from what I've read (so far) that GCC currently does. I'm first wondering if these are comtemplated future things, or things that have been deliberately excluded for good reason, or even perhaps things that once existed and were removed for some reason. I expect there are people here that will know the answers! ;-) The basic project description: The machine is very strange in modern terms. It doesn't have registers, it executes code in reverse Polish, the integer data type is a degenerate form of the floating point data type, pointers are magic, there are no page tables, and the word size isn't a power of 2, just to start. Oh, and the integers (floating point mantissas with exponent of zero) are sign/magnitude. And boolean quantities are even/odd, rather than zero/nonzero. Clearly not a terribly good fit for a normal GCC target, but I have some hope here. For one thing, the actual target will be a soft emulation of the original hard machine, and I have control over the instruction set for the emulator. So I can introduce new instructions that do 2's complement numbers and IEEE math, *but*, I still need to maintain the old stuff too. The idea is to read existing code files, which retain a good deal of symbolic information, and build appropriate trees. Since the code is reverse Polish this this isn't all that hard in many cases. Since GCC supports nested procedures I shouldn't have to do terribly clever hacks to deal with that aspect of the machine. Obviously I have to write a frontend to do this, and obviously it will be a heck of a lot of work. We have code that will take an existing codefile apart and build trees of our own, which can be used to regenerate the existing code. I'd like suggestions on where I might start for a frontend. Should I start with the toy compiler? Should I try to strip down the C frontend? Hopefully I shouldn't start from scratch? A problem (I think) is that I have one or two basic new number formats. I see that GCC doesn't support ones comp or sign-magnitude integers. Understandable, and no complaints. However, my impression at the moment is that I need to add just exactly that form of support. And ideally this woudl be a new data type (rather than a C++ class with methods) that was still arithmetic in nature, so that the optimizer passes can do all the common things to simplify the math. (In particular the compilers that generate this code tend to pessimize simple constants into a series of small literals and insert/rotate instructions; it would be good to do constant folding.) I would also expect that I should be able to define conversions from this representation to 2s comp in some cases - for instance, small positive literals can be done in either arithmetic base, and are far faster in 2s comp than in emulated sign/magnitude instructions. I would hope I could add optimizations that would deal with this. Does it seem feasible to be able to add a new math data type and still expect things to work? Or is this a 'flat impossibility'? Any pointers on what I should start looking at in the compiler? I think I can handle the boolean odd/even problem simply by generating an implicit "and =1" to every result before testing it, and then hoping the optimizer can perhaps convert that to a bit test and branch instruction rather than a literal 'and' in many cases. Does this seem like a reasonable approach, or should I consider implementing a second boolean data type with appropriate conversions? The one other thing I'm concerned (greatly) about is whole program optimization ability. SInce I'm reading an entire program, the "source file" will contain all code in the program. The only outside routines will be in the OS or in dynamic link libraries. Of which there are zillions, but fortunately with decent parameter and return info descriptions. I'm hoping that the optimizer would be able to analyze the entire program and determine ALL places global (or at least global to the current nested procedure) variables are referenced and modified, at least directly. I'd hope that nested procedures could be analyzed sufficiently that decisions could be made on inlining them, and possibly discarding the actual procedure if all invocations get inlined. (It is common to see procedures where the
Can't commit to gcc-4.1
Is anything wrong with SVN, or did my authorization to commit somehow fall through the cracks? Thomas $ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog testsuite/gfortran.dg/multiple_allocation_2.f90 Waiting for Emacs...Done svn: Commit failed (details follow): svn: Authorization failed svn: Your commit message was left in a temporary file: svn:'/home/ig25/gcc/branches/gcc-4_1-branch/gcc/svn-commit.4.tmp'
Re: Can't commit to gcc-4.1
On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote: > Is anything wrong with SVN, or did my authorization to commit somehow > fall through the cracks? Is it maybe an anonymous checkout? Check svn info. -- Daniel Jacobowitz CodeSourcery
Re: Can't commit to gcc-4.1
On Sun, May 28, 2006 at 02:43:20PM -0400, Daniel Jacobowitz wrote: > On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote: > > Is anything wrong with SVN, or did my authorization to commit somehow > > fall through the cracks? > > Is it maybe an anonymous checkout? Check svn info. That was it. Thanks a lot! Thomas
Re: An assortment of questions
> The machine is very strange in modern terms. It doesn't have registers, it > executes code in reverse Polish, the integer data type is a degenerate form > of the floating point data type, pointers are magic, there are no page > tables, and the word size isn't a power of 2, just to start. Oh, and the > integers (floating point mantissas with exponent of zero) are > sign/magnitude. And boolean quantities are even/odd, rather than > zero/nonzero. >... > Does it seem feasible to be able to add a new math data type and still > expect things to work? Or is this a 'flat impossibility'? Any pointers on > what I should start looking at in the compiler? It's unclear whether you're trying to generate code to run on this machine, or have gcc accept binaries for this machine as a "sourse" language, or both. If you're trying to generate code for this machine, then I have to ask why. You mention that you're running on an emulator anyway, so why not just run new code directly for the machine running the emulator, which is persumably a vaguely sane architecture. If you're trying to use gcc as a binary translator (ie. feeding the original binaries in and getting something a native application out) then I would seriously consider writing a translator that generates C or C++, then feeding that through a normal compiler. Either way, it doesn't sound like hacking gcc is worth the effort. I find it hard to believe that people are actually writing new code for such a bizarre machine. Paul
"Authorization failed" for commit?
I just tried to commit the fix for PR 27470, a gfortran 4.1 regression, and I got the error message: $ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog testsuite/gfortran.dg/multiple_allocation_2.f90 Waiting for Emacs...Done svn: Commit failed (details follow): svn: Authorization failed svn: Your commit message was left in a temporary file: svn:'/home/ig25/gcc/branches/gcc-4_1-branch/gcc/svn-commit.2.tmp' Does anybody have any idea what's wrong? Thomas
Modifying ARM code generator for elimination of 8bit writes - need help
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 memory for data, linux in console mode is possible, but graphical environments are very limited... The idea to overcome this problem is to a) activate data cache in writeback mode for the external memory. b) modify the gcc code generator. "strb" opcode is transformed to "swpb". swpb will load the cache because of the read-modify-write, and at cache writeback time, the whole cached half-line will be written back, eliminating the 8bit write problem. I have proven the solution with an assembler program, but I think I need some help modifying the compiler 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? regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
configure: error: expected an absolute directory name for --prefix
Dear all, Doesn't autotools support relative paths in configure? Or is this a particular issue of GCC's build system? Cheers, Manuel.
Re: configure: error: expected an absolute directory name for --prefix
On May 28, 2006, at 1:58 PM, Manuel López-Ibáñez wrote: Dear all, Doesn't autotools support relative paths in configure? The reason why you cannot pass relative paths for --prefix is because --prefix is passed down to all of the makefiles and others which is going to have the wrong prefix. Just use an absolute path constructed with `pwd`/.. . -- Pinski
Re: configure: error: expected an absolute directory name for --prefix
Thanks Andrew, that is exactly what I did, although I was expecting configure to be smart enough to use that trick on my behalf. On 28/05/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: On May 28, 2006, at 1:58 PM, Manuel López-Ibáñez wrote: > Dear all, > > Doesn't autotools support relative paths in configure? The reason why you cannot pass relative paths for --prefix is because --prefix is passed down to all of the makefiles and others which is going to have the wrong prefix. Just use an absolute path constructed with `pwd`/.. . -- Pinski
Does anyone have Vlad's CSE speedup patches from many years ago
Hello, When fwprop gets approved, CSE path following will disappear. We lose virtually no optimization opportunities. Still, it should not be very hard to make CSE work on extended basic blocks (but without rescanning like path following does). All that would be needed is infrastructure in cse.c to do a pre-order walk starting from some basic block, and a way to store and roll-back the state of the various tables that cse.c builds. I found out long ago that even longer ago Vlad had patches to keep the state for basic blocks and re-using it. The latest message mentioning this work is http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01166.html, and apparently Vlad's patches never made it out of the Cygnus network. So... Does anyone of you pack-rats still have these patches? Maybe there is code in them that I can re-use, or at least learn from because right now, even in my cleaned-up-and-cut-down version of cse.c (down to 5000 lines) I still can't make a whole lot of sense of all the tables that are used in that pass. I hope[*] you can help. Thanks, Gr. Steven [*] I know hope is delayed disappointment, but trying doesn't hurt ;-)
Re: Does anyone have Vlad's CSE speedup patches from many years ago
Steven Bosscher wrote: Hello, When fwprop gets approved, CSE path following will disappear. We lose virtually no optimization opportunities. Still, it should not be very hard to make CSE work on extended basic blocks (but without rescanning like path following does). All that would be needed is infrastructure in cse.c to do a pre-order walk starting from some basic block, and a way to store and roll-back the state of the various tables that cse.c builds. I found out long ago that even longer ago Vlad had patches to keep the state for basic blocks and re-using it. The latest message mentioning this work is http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01166.html, and apparently Vlad's patches never made it out of the Cygnus network. So... Does anyone of you pack-rats still have these patches? Maybe there is code in them that I can re-use, or at least learn from because right now, even in my cleaned-up-and-cut-down version of cse.c (down to 5000 lines) I still can't make a whole lot of sense of all the tables that are used in that pass. I am sorry to say but I think it was lost. The patch was created in 1998 or 1999 and posted on internal website with benchmark results. During IT reorganization after Redhat bought Cygnus, the page was lost. As I remeber the big speedup was achieved on some specific programs. I did not submit the patch (into Cygnus repository or egcs one) because the code generated with the patch was a bit worse. Although originally the code was supposed to be the same. I failed to find the reasons for this that time. Vlad
Re: An assortment of questions
On May 28, 2006, at 12:19 AM, Loren Wilton wrote: I'm looking at the need to build a very comprehensive code optimizer and generator for a very strange (antique but still used mainframe) machine. Which machine out of curiosity?
Errors while building bootstrap GCC for "mipsisa32-elf" target
Hi all, I am new to this list and GCC compiler. I am trying to build GCC4.1.0 for "mipsisa32-elf" target. I would appreciate if someone could help me out in resolving the errors during build process. The detail is as follows: OS: Fedora core5 Default GCC compiler installed on system: gcc 4.1.0 The steps followed by me are as follows: 1. Configured binutils version 2.16.1 by using following command and build: [EMAIL PROTECTED] build]$ ../src/configure --target=mipsisa32-elf --enable-languages=c --prefix=/home/monika/GCC/install Note: I have installed binutils in GCC's install directory. 2. Configured GCC by using following command: [EMAIL PROTECTED] build]$ ../src/configure --target=mipsisa32-elf --prefix=/home/monika/GCC/install 3. I got the following error during build process: cc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o libgcc/./gthr-gnat.o libgcc/./unwind-c.o make[3]: mipsisa32-elf-ar: Command not found make[3]: *** [libgcc.a] Error 127 make[3]: Leaving directory `/home/monika/GCC/build/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/home/monika/GCC/build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/monika/GCC/build' make: *** [all] Error 2 It was not able to find AR executable for mipsisa32 while it was build in install directory. I temporarily solved this error by editing Makefile and added path of 'AR' executable explicitly. 4. I again got the following error after step 3: checking for additional debug build... no checking for extra compiler flags for building... checking for thread model used by GCC... single configure: WARNING: No native atomic operations are provided for this platform. configure: WARNING: They cannot be faked when thread support is disabled. configure: WARNING: Thread-safety of certain classes is not guaranteed. configure: error: No support for this host/target combination. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/monika/GCC/build' make: *** [all] Error 2 5. I also tried to build with option "--enable-languages=c" but I got the following error: [EMAIL PROTECTED] build]$ ../src/configure --target=mipsisa32-elf --enable-languages=c --prefix=/home/monika/GCC/install ../../../src/libssp/ssp.c:161: error: too many arguments to function 'fail' ../../../src/libssp/ssp.c: In function '__chk_fail': ../../../src/libssp/ssp.c:168: warning: incompatible implicit declaration of built-in function 'strlen' ../../../src/libssp/ssp.c:168: warning: passing argument 2 of 'fail' makes pointer from integer without a cast ../../../src/libssp/ssp.c:168: error: too many arguments to function 'fail' make[3]: *** [ssp.lo] Error 1 make[3]: Leaving directory `/home/monika/GCC/build/mipsisa32-elf/libssp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/monika/GCC/build/mipsisa32-elf/libssp' make[1]: *** [all-target-libssp] Error 2 make[1]: Leaving directory `/home/monika/GCC/build' make: *** [all] Error 2 6. I also tried with option "--with-newlib" however got following error: ../../../src/libiberty/regex.c: In function 'xregfree': ../../../src/libiberty/regex.c:8121: error: 'regex_t' has no member named 'fastmap_accurate' make[2]: *** [regex.o] Error 1 make[2]: Leaving directory `/home/monika/GCC/build/mipsisa32-elf/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/home/monika/GCC/build' make: *** [all] Error 2 [EMAIL PROTECTED] build]$ ../src/configure --target=mipsisa32-elf --with-newlib --prefix=/home/monika/GCC/install Thanks in advance, Monika
Re: Segment registers support for i386
Ross Ridge wrote:
You won't be able to. You're going to need to write your own code that,
during the conversion of the tree to RTL, creates RTL expressions which
indicate that the memory references use segment registers. This probably
won't be easy since there are a lot of contexts where your "far" pointer
can be used. I suspect this is where you're going to give up on your
project, but if you do then RTL expressions you'll need to create should
probably look like:
(mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
After getting GCC to generate expressions like these, then it's a
realtively simple case of modifying ix86_decompose_address() to handle
the unspec. You might also need to change other backend code for
handling addresses.
Ross Ridge
Hi,
if I understand well, to make gcc generating rtx according to an
__attribute__((far("fs")))
on a pointer I only have to add or modify rtx in the i386.md file and
add an UNSPEC among the constants ?
Actually, it is not specifically for this attribute but more to
understand how does gcc manage attributes internally.
What I understand is that there is two kind of managment for attribute :
- The attribute is handled before the tree -> rtl conversion so some
code has to be added
in the C source code and this code removes the attribute from the
tree once it has
finished its job.
- the attribute is handled during the tree -> rtl conversion so some
code is added in the .md
file and gcc consider the attribute node of the tree as an UNSPEC rtx class.
After what it looks for an rtx pattern which match with this UNSPEC.
Therefore, I can consider the following relationship:
(mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
| ||
|
\/ \/ \/
\/
int * __attribute__((far("fs"))) p;
If these are right, I have some questions:
- does (reg:HI fs) care about the type of the parameter fs ? (a
string in the C code)
- how does gcc recognize such an expression ? I mean (reg:SI var) is
a register in SImode
but there is no indication about the storage of p in the C souce.
Does it begin by
identifying that the pattern matches the unspec and then try to put
p in a register as
written in the pattern?
Thanks for your help.
Have a great day.
--
Rémy SaissyJabberID: [EMAIL PROTECTED]
Web: http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.
