tdn@cmu-cs-spice.ARPA (Thomas Newton) (04/09/85)
So far, I have run into the following problems with Megamax C:
BUGS
----
(1) The Toolnames file is not quite right and needs to be changed
before using CONVERT. This problem is fairly trivial to fix.
The most important fix is to remove 'Double' from 'Toolnames';
otherwise, the compiler stops recognizing the stuff in fmath.h.
(2) Programs created using Megamax C do not seem to be compatable
with SkipFinder. The Mac dies with a 'deep s**t alert ID' of
3 whenever a Megamax C program exits and SkipFinder is active.
I first noticed this problem in a program that I compiled. I
confirmed it by trying to quit from Megaroids and from a null
program ("main() {}") while SkipFinder was active. I haven't
seen any other programs that are incompatable with SkipFinder,
so I'm assuming that the bug is probably in the C compiler.
MISFEATURES
-----------
(3) Desk accessories created using Megamax C are not 'purgeable',
i.e. they cannot be thrown out of memory when space is tight
and be swapped back in as needed. I used the Resource Mover
to set the purgable bit on one DA, and was "rewarded" with a
bomb when I tried to use it. (Of course, this particular DA
was bombing in different ways before, seemingly related to a
lack of free memory on my 128K Mac when running MacPaint...)
The compiler does seem to generate working desk accessories;
it's just that it would be nice to be able to generate desk
accessories that are purgeable. All of the desk accessories
supplied for Apple, by instance, are purgeable. So I'm not
sure whether to classify this as a bug or a misfeature.
(4) There is no debugger, and the editors supplied (FILE and EDIT)
are downright pitiful when compared to Unix Emacs, GNU Emacs,
20 Emacs, Hemlock, or even less powerful editors like Oil. I
don't actually know of any decent editors on the Mac, so this
really isn't an indictment against the Megamax compiler per se.
(What I would really like to have is a Unix EMACS-style editor
that takes advantage of the mouse like Microsoft WORD without
sacrificing keyboard control or programmability.)miles@siemens.UUCP (01/27/86)
I am currently using Megamax C and am having difficulty linking my
compiled modules together. I am trying to link C programs that have
successfully run on UNIX. After compiling the modules without error I
get an error from the Megamax linker that reads:
Segment 'main' > 32K
Press RETURN to continue
This appears after all the modules have already seemingly linked. The
documentation is of no help in trying to determine what this message
might mean.
Additionally, a few of my compiled modules won't link at all. When I
add them to the list of modules to link I receive a message like:
Couldn't find (some) label(s)
$19 $27 $56
Press RETURN to continue
Removing these modules from the list of modules to link stops this error
from occurring but doesn't really solve my problem.
I was wondering if anyone knows what these errors mean and how I might
correct them. Remember, I am using C code that compiles, links, and runs
successfully on UNIX.
Thanx.
Miles Feinberg
Siemens
(609) 734-6562
UUCP: ihnp4!siemens!milesstew@harvard.UUCP (01/29/86)
In article <97200002@siemens.UUCP> miles@siemens.UUCP writes: > > I am currently using Megamax C and am having difficulty linking my >compiled modules together. I am trying to link C programs that have >successfully run on UNIX. After compiling the modules without error I >get an error from the Megamax linker that reads: > Segment 'main' > 32K > Press RETURN to continue Macintosh programs are divided into "segments" which must be less than 32K bytes. To fix this, divide your program into overlays. To do this, just put in the line overlay "main" at the beginning of half of your source files, and overlay "seg2" at the beginning of the other half. If these are still too big, divide again. Optimally, you would figure out which routines call which others and divide so as to minimise cross-segment calls, and use UnloadSeg() to dispose of segments not being used. > Couldn't find (some) label(s) Maybe it is related and will go away when you segment? Stew Rubenstein harvard!stew
grimshaw@uiucdcsp.CS.UIUC.EDU (01/29/86)
While I don't have my Megamax manual here at work, I believe that the maximum segment size in Megamax C is 32K words. I know that this is the case for DRVR code resources under Megamax, such as desk accessories and drivers. Look in the section on the linker, and on special linker information. I think that the information you want is in Ch. 4. Andrew Grimshaw RA University of Illinois
bill@utastro.UUCP (William H. Jefferys) (01/29/86)
In article <97200002@siemens.UUCP>, miles@siemens.UUCP writes: > > I am currently using Megamax C and am having difficulty linking my > compiled modules together. I am trying to link C programs that have > successfully run on UNIX. After compiling the modules without error I > get an error from the Megamax linker that reads: > Segment 'main' > 32K > Press RETURN to continue Megamax will not load segments larger than 32K. You have to use the "overlay" feature to break up your code into smaller pieces. Read the manual for information. -- Glend. I can call spirits from the vasty deep. Hot. Why, so can I, or so can any man; But will they come when you do call for them? -- Henry IV Pt. I, III, i, 53 Bill Jefferys 8-% Astronomy Dept, University of Texas, Austin TX 78712 (USnail) {allegra,ihnp4}!{ut-sally,noao}!utastro!bill (UUCP) bill@astro.UTEXAS.EDU. (Internet)
lewis@axiom.UUCP (Lewis Gordon Pringle Jr.) (01/29/86)
miles@siemens.UUCP writes: >successfully run on UNIX. After compiling the modules without error I >get an error from the Megamax linker that reads: > Segment 'main' > 32K > Press RETURN to continue Because of the way the Macintosh Segment Loader works (2 bytes offset in jump tables), mac code segments are limmited to 32K. I think that you will find that ALL Mac C compilers, will have the same complaint. > Additionally, a few of my compiled modules won't link at all. When I >add them to the list of modules to link I receive a message like: > Couldn't find (some) label(s) > $19 $27 $56 > Press RETURN to continue > Removing these modules from the list of modules to link stops this error >from occurring but doesn't really solve my problem. What version of the MagHax system are you using? Are you using the batch thingy ? What could have happened if you were, is that you ran the compiler, it produced errors, and a .o file, and the batch guy just continued on its way merrily linking. The compiler DOES produce a .o file when it fails, and the linker does barf in a manner simmilar to the one that you described when given the result of a failed compile. Be sure to check the 'status ()' of compiles in batch files. Appropriate Remarks, Lewis. -- ---------- The facts expressed herein are subject to change without notice. UUCP: {humming,linus,security,harvard}!lewis@axiom.UUCP
vomlehn@bubba.UUCP (01/31/86)
> Additionally, a few of my compiled modules won't link at all. When I > add them to the list of modules to link I receive a message like: > Couldn't find (some) label(s) > $19 $27 $56 > Press RETURN to continue > Removing these modules from the list of modules to link stops this error > from occurring but doesn't really solve my problem. Surprise! Some of the object modules in the C library won't link. I ran into that problem with setjmp/longjmp. I used the librarian to extract the module, turned it into a compilable form and compiled it. I didn't bother to put this back in the library, but when I linked with the .o file, it linked correctly. I haven't actually verified that it works yet because I only overcame this hurdle last week and haven't touched the code yet, but it looks like it works. David M. VomLehn ...ihnp4!ut-sally!cositex!vomlehn
bhyde@inmet.UUCP (01/31/86)
I occationally get undefined local symbols in my Megamax
links. The easy way to make this bug appear is:
static foo();
ProcPtr actions[] = { foo, foo, foo}; /* Table of subp. pointers */
foo()
{
...
}
This will give rise to three (wierd) undef symbols at the end of
the link, all named "foo". Removing the static declaration
will fixs the problem.
I have seen the undefined local symbol errors too, i.e. names
like $12, $324. I diagnosised the problem using the disassembler.
I don't recall what construct caused the problem.
-ben hyde, cambridge.gus@Shasta.ARPA (01/31/86)
> > > miles@siemens.UUCP writes: > >successfully run on UNIX. After compiling the modules without error I > >get an error from the Megamax linker that reads: > > Segment 'main' > 32K > > Press RETURN to continue > > Because of the way the Macintosh Segment Loader works (2 bytes offset > in jump tables), mac code segments are limmited to 32K. I think that you will > find that ALL Mac C compilers, will have the same complaint. Popycock! The 32K byte segment limit has little to do with the jump table. It is easy for a linker to provide a secondary jump table at the start of the segments which provides four byte offsets. The main problem has to do with the 68000's 16 bit offset addressing modes. The SUMACC C compiler produces 32 bit absolute code. This requires an extra relocation phase, but it does allows large model code. At a Stanford Mac Users Group Developers meeting last fall, Jim Goodnow II, the creator of Mac Aztec C, told us that he was working on a compiler which could create large model code. Also, 32K is simply the limit for GUARANTEED addressability. It just means that one part of the code cannot reference code or data which is more than +/- 32K away. This is hard for a compiler to take advantage of, however. G U S