albaugh@dms.UUCP (Mike Albaugh) (02/08/89)
I am trying to port gcc. Since the only system I have
capable of compiling gcc is a vms vax, I am currently stuck at
version 1.22 (no flames please, unless accompanied by a check
sufficient to buy me a "real unix (tm)" machine). Anyway, I finally
got it to compile without errors, but now it aborts if I feed it
hello.c (of course that's the first program I tried :-), but not the
last). The abort is _reported_ in _fixuns_truncdfsi (or something of the
like) in gcclib, but appears to _really_ emanate from insn_extract()
called from regclass(). Tracing back a ways, this all seems to stem from
trying to figure out the "best class" of register for a given insn.
Since I don't have any floating point hardware, I don't have any define_insn's
for floating point. I presumed (apparently incorrectly) that gcc would
notice this and use libcalls. Anyway, the whole subject of "register class"
seems to key on the #define REGISTER_CONSTRAINTS which is generated by
gen-config when it sees _any_ constraint whatsoever (not just register
constraints). Since my machine is a load/store architecture, I can't
define movesi without _some_ constraints. I'm using something like:
"general_operand" "=r,m" and
"general_operand" "rmI,r"
and picking the right template. Note that there are no distinct flavors
of register, but at least one of the operands must be _some_ register.
I might be able to re-write most of my md without constraints, but some
of the pre-defined ones baffle me. While I'm at it, has anyone sleuthed
out a list of the required pre-defined insns. By required I mean you
either don't compile or dump core if you don't have all of them. The final
fix needed to get an error-free compile was to define "call_value",
which is not even mentioned as being defined, let alone essential.
Wierd piece of evidence - this does not happen if I compile:
char *fred() { return "hello world\n"; }
so it seems this path is only exercised when a subroutine call is processed.
I know this is hardly an exhaustive test, but I found it interesting.
Please don't think I'm just grousing. I like the structure and
much of the rest of gcc. I just need a little help across the more
obscure points. I apologize for the hand-waving in some of the above,
but I'm telnet'd two deep to get to a machine that can post news and
don't have real good access to my sources from here.
Thanks in advance for any pointers.
Mike
| Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)rcbaps@eutrc3.UUCP (Pieter Schoenmakers) (02/14/89)
Hi, I've got a question similar to the questions already posted. At the moment I am (trying to implement) implementing GCC (version 1.16, ahem; version 1.33 'very soon now') on an Apollo workstation to generate code for a processor people at our university are designing. The 'trying to implement' seems to be going well (gcc compiles, this means), but I do get fatal signals when running the compiler (on a program which just adds the numbers between 1 and 100). So, my question is: what do those fatal signals mean? Obviously that something is wrong. But exactly what information can one derive from the signal number? Thanks in advance for any information regarding this topic, ---Tiggr