albaugh@EDDIE.MIT.EDU (Mike Albaugh) (01/29/89)
Dear GNUfolk:
Hello, and before I get started, THANKS!!
I am trying to do something perhaps a little bit wierd,
namely produce a 680x0 cross-compiler running on a VMS vax.
(one uses what one has :-). Anyway, two of these are really what
I would call bugs, while the rest are probably just the result of
the wierd things I'm trying to do or my denseness.
All of this is with a locally compiled version of 1.22,
compiled with the binary from Decus, which may also be 1.22.
Without said binary I would have be SOL, as no other compiler
that I have access to can cope with the extremely long lines
that your cpp produces from the extremely long macros (which
also choke all the other pre-processors I tried). If I could, for
example, compile GCC for any other system (say Xenix/386), I might
not have to wrestle VMS.
The distribution I'm working with is 1.22, again as supplied
by Decus, plus some hand-editting to delete end-of-file cruft injected
by the tar reader they supplied (have I got your sympathy yet?)
Anyway, bug #1 is that the makefile supplied did not indicate
a dependancy on insn-codes.h for the files varasm.o, integrate.o,
or insn-emit.o, although those .o's do, in fact seem to depend on it.
Mercifully, it croaked with file-not-found rather than using an old version
for some of the .o's and a new version for the rest. The mysterious part
is that it _didn't_ croak the first time I built it (for the vax), but
did after I copied everything off to another directory and tried to make
a 68000 version. I should mention that I'm using a public-domain "make",
and first suspected it, but verified the lack of dependancy independantly.
I must admit that I don't know what .PRECIOUS is _supposed_ to do and that
may have something to do with it, but am curious.
Bug #2 is a warning from GAS that it is "ignoring attempt to
re-define symbol" in parse.tab.s. Examination of the .s file (no mean
feat, since the VMS version tries real hard to delete it) shows the
offending re-definition to be the result of parse.tab.c containing
both:
int yydebug = 0; /* which results in yydebug: .long 0 */
and later:
extern int yydebug; /* which results in a comn of yydebug */
Misc headache #1 is that the motorola syntax liberally commented
about in tm-68k.h and the like bears little resemblance to the syntax
specified by Motorola in their assembler manual, and accepted by the
third-party assemblers we have here. I hacked up a tm-mot file to do
most of it, but don't really have the info on floating point or 68020
extensions, so it's going to barf if I ever compile anything that needs
them. Did anybody send in a complete "tm-mot", and where can I get it?
Minor headache/nit/question is move-if-change. If it doesn't
move, I remake the files. If it does, I remake everything that depends
on them. Now, of course, I'm not actually using move-if-change because
my vms vax doesn't have a Bourne Shell, but I coded up an equivalent
and still wonder what it was supposed to do.
One last question: does 1.3x compile under vms? I don't care
a whole lot about generating vax code, but would like to see if it
does a better job of recognizing when it could use the 68000 mul/div
instructions, and just plain want the latest and greatest (as long as
it works). In regard to mul/div:
main()
{
int i,j;
short k,l;
k = 5;
l = 3;
i = k*l;
k = i/(short)5; /* cast actually makes no difference */
printf("%d %d %d %d\n",i,j,k,l);
}
produces:
main:
link a6,#0
movem.l d3/d2,-(sp)
moveq.l #15,d2 # -O folds this
pea 5
move.l d2,-(sp)
jsr _divsi3 # library call for what could be two insns
. # a divs and (optionally) ext.l
.
But since I am assigning to a short, I clearly am not expecting more than 16
(15, actually) bits of quotient.
I realize that:
a) some lawyerly reading of the ANSI draft says the i = k*l is allowed
to screw up (truncate to 16 bits then sign extend)
and b) full constant folding across expressions is too much to ask for
(and would have defeated the purpose of the test)
and c) few compilers recognize this case
but I am currently using a compiler (Greenhills) that only sometimes
fails to recognize the above, and usually only in the presence of other
brain-damage, so I've gotten used to grepping (or the vms equiv) my .s
files for library calls and I'm going to be examining a lot of code :-(
Why, you ask, is this bozo mucking with our compiler when he already
has one? Well Greenhills has lousy support, still a lot of bugs, no source,
and no ANSI compliance (yet). Besides, I want to take this compiler home
and run it on my CPM68K system, which just does not like vms binaries.
Also (finally) I am doing this primarily as a warm-up to the
_real_ job of re-targeting to a home-grown "simplified architecture"
(RISC is a mktg term now, not a technical one) processor. I will undoubtedly
be bugging you more in the future as I try to write an md file, but hey,
when I'm done you (and the world in general) get a compiler for a chip
that does a MIP/$ (if you have a good cache). More info available if you
are interested.
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)