dclemans@mntgfx.mentor.com (Dave Clemans) (03/01/88)
This is what I've seen so far trying to port over a large working
package from Megamax C version 1 to Megamax Laser C:
1. Generation of bad code
in a routine like
foo()
{
.
.
.
if (...)
{
if (...)
return;
}
#ifdef bar
bar is not defined, so this block goes away
#endif
}
at the end of the routine there was a garbled branch instruction,
that the outer "if" tried to jump into the middle of. The instruction
to restore register variables was missing. This was relatively
easy to find with the traceback facilities of the shell.
presumably what happened was that the generated code originally was
bne ret
ret: restore regs
unlink
rts
and then the optimizer came along and didn't collapse the branch correctly
2. libraries/linker
ar seems to create libraries without a "ranlib" index by default. However
if the linker sees a library without a "ranlib" index it seems to go into
an infinite loop.
once a library has a "ranlib" index ar intermittently has problems updating
members in the library; it sometimes says that the library has a bad format.
This doesn't happen consistently so I don't know what causes it.
3. cc
cc supports a -l switch to reference libraries, and a LIBPATH environment
variable to help it find libraries. The ability to use this facility would
be extremely useful, as what I'm trying to do is large enough that I have
trouble fitting it into the 127 max command line lengths of make.
However cc seems to process all -l switches first, and scans those libraries
first before any other files are looked at (presumably because of how cc
builds the command line for the ld). Since there are no undefined references
yet, it never loads anything from those libraries, thus the -l switch to cc
is TOTALLY and COMPLETELY USELESS! "-l" switches should signal that the
library is searched in the order that the switches appear in the argument list;
if a "-l" switch appears after a filename, the library must be searched AFTER
the object for that filename is loaded.
If you reference libraries via a real pathname, everything works fine.
4. utilities
Presumably "cp" is a command to copy a file; experimenting with it definitely
makes it look like it wants to copy a file. However it gives the file "copy"
a read-only attribute. With that attribute you can't modify, edit, delete, etc.
any "copied" file within the shell environment.
*** I may find more bugs; the package is still having problems
5. miscellaneous notes
(These aren't bug reports...)
If there's going to be any further problem in getting the real documentation, could
someone at Megamax on what the libx library is? From the header file it looks interesting.
It looks like the compiler now has only 8 significant characters, vs. 10 characters in V1.
The "overlay" keyword is gone
By default you get a 8KB stack; to get more declare and initialize a long integer _stksize
with the desired stack size.
Dave Clemans
dclemans@pdx.mentor.comlbl@druhi.ATT.COM (LocklearLB) (03/04/88)
In article <1988Feb29.101120.12013@mntgfx.mentor.com>, dclemans@mntgfx.UUCP writes: > It looks like the compiler now has only 8 significant characters, vs. 10 characters in V1. I specifically ran some tests of this feature. The tests consisted of assigning values to two variables that were identical up to N characters and printing out the results. As far as I can tell, Laser C uses flex names (i.e. no preset variable length ) but, the tools they have provided only print out the first 8 characters or so. I can't figure out why they didn't make the tools work with flexnames, unless you need to give them some option to work with flexnames. I think I'll wait until the full documentation arrives before making any more comments. Barry Locklear
michel@megamax.UUCP (Michel Rynderman) (03/10/88)
In article <2747@druhi.ATT.COM> lbl@druhi.ATT.COM (LocklearLB) writes: >In article <1988Feb29.101120.12013@mntgfx.mentor.com>, dclemans@mntgfx.UUCP writes: >> It looks like the compiler now has only 8 significant characters, vs. 10 characters in V1. >Barry Locklear The compiler has 255 significant characters. The linker had a bug in it that printed out only 8 characters but that has since been fixed. Both the symbol namer and the disassembler print as many characters out as there are. Michel@megamax