kkaempf@rmi.UUCP (10/30/87)
Hi ! The following text comes from a friend of mine, who doesn't has access to the Net. You may send comments to me via E-Mail, I will pass them to him. Klaus Kaempf - - - - - - - - - After using my new Lattice C 4.0 (they did a great job!) for a few days, I found out some things that might be interesting for others as well: "-ce" on "LC1" will inhibit output of the source (de-manxify, same as LC3.10) in case of an error. Warning 96 won't be issued unless you specify "-cf". "-c+" will suppress warning 22. "#pragma syscall" uses address 4 as library base pointer. Using "sizeof(struct unknown)" still will not give you an error and "-ct" still does not work (both same as LC3.10). This can be fixed with the following patch: Change the word at offset $4751 from $2000 to $0000 (otherwise the compiler will override the option you choose) and the word at offset $4558 from $660A to $670A (so the compiler will behave unchanged if "-ct" is NOT specified, see page C-10, NOT 8-3). Both offsets are 16-bit-offsets! These modifications don't seem to have any side effects, but who knows? Now all undefined structs etc. will generate a warning (after the complete source has been processed, so the line number should be ignored). But now you will have to fix your Amiga include files cause these will use lots of pointers to undefined structs (remember the old 3.03 and its warnings if you did not include almost everything?). And now a bit of criticism (John Toebes, are you listening?): Give us back our address register variables! My favorite benchmark (a sieve) now runs about 15 secs instead of 9 secs under LC3.10 for the first million prime numbers (no output of course). At least offer an option the way Aztec does (+r) if not using small data (= base relative). And, by the way, I could not get the compiler to use A3 as register, only A2, meaning I got only a single address register left! And if I choose not to use "#pragma libcall/syscall" it should be possible to use A6 as either a register variable or the base register (now A4). In addition you should release documentation on the new object format (library indexing). You did so in the "read.me" to LC3.10 for the base relative addressing and usage of a well documented standard object format has always been the reason I preferred Lattice to Aztec (both are still great compilers and if I need "#asm" I use Aztec of course). The object format defined by MetaComCo had to be enhanced, but then, please tell us about these improvements. The preprocessor symbol "LATTICE_C" should be defined the way Turbo C (gee, what's that?) does it (version number) in addition to those (now undocumented) symbols (who wrote the manual?). And, by the way, "OMD" does not recognize "BCS". Goodbye for now, I hope this helped someone. Ralph Babel, Falkenweg 3, D-6204 Taunusstein, West-Germany. Sorry, no E-mail.
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (11/02/87)
In article <789@rmi.UUCP> kkaempf@rmi.UUCP (Klaus Kaempf) writes:
<The preprocessor symbol "LATTICE_C" should be defined the
<way Turbo C (gee, what's that?) does it (version number) in
<addition to those (now undocumented) symbols (who wrote the
<manual?).
Sorry, but the latest draft of the ANSI C standard (which is what
Lattice is working on conforming to) explicitly *forbids* preprocessor
symbols from being defined. One of the most major things done wrong,
and hopefully to be fixed (or at least a way around pointed out, like
_LATTICE_ or some such) in the next draft.
I can't tell but it looks like LATTICE_C is defined, but not to what
you want it to be defined to. In which case, Lattice did it wrong, and
apparently twice.
<mike
--
[Our regularly scheduled .signature preempted.] Mike Meyer
The Amiga 1000: Let's build _the_ hackers machine. mwm@berkeley.edu
The Amiga 500: Let's build one as cheaply as possible! ucbvax!mwm
The Amiga 2000: Let's build one inside an IBM PC! mwm@ucbjade.BITNETtoebes@sas.UUCP (John Toebes) (11/04/87)
In article <789@rmi.UUCP>, kkaempf@rmi.UUCP (Klaus Kaempf) writes: > After using my new Lattice C 4.0 (they did a great job!) for > a few days, I found out some things that might be > interesting for others as well: > > "-ce" on "LC1" will inhibit output of the source > (de-manxify, same as LC3.10) in case of an error. Warning 96 > won't be issued unless you specify "-cf". > "-c+" will suppress warning 22. Sorry these didn't get into the documentation. They were added a little late in the development cycle. -cf is an extremely powerful option. When you use it it will issue a warning message whenever you call a function for which no prototype is present. I have used this to find numerous bugs in existing programs that suposedly have been tested and working. (One passed a screen pointer to OffMenu). > > "#pragma syscall" uses address 4 as library base pointer. Actually what it does is load _AbsExecBase ($0004) into a register giving the library base. This is exactly what you would do if you coded it in Assembler. > > Using "sizeof(struct unknown)" still will not give you an > error and "-ct" still does not work (both same as LC3.10). I wasn't aware of these bugs, but you can be assured that they will be fixed. When I started development of 4.0 I got a dump of the Lattice Bug Database and fixed everything that they had listed as outstanding. I would be interested in knowing when and to whom this was reported so I can ensure that bugs like this never get lost. > This can be fixed with the following patch: > (some patchs code given...) > These modifications don't seem to have any side effects, but > who knows? I will post an official patch for this. There is already a mechanism defined for patching the compiler so you can readily tell when you are using a patched compiler AND what patches have been applied. > Now all undefined structs etc. will generate a warning > (after the complete source has been processed, so the line > number should be ignored). But now you will have to fix your > Amiga include files cause these will use lots of pointers to > undefined structs (remember the old 3.03 and its warnings if > you did not include almost everything?). Not sure what you are getting at here. The compiler will generate an error when you USE a structure which hasn't been declared and a warning when you declare a pointer to the unknown structure. If you have a program that illustrates a problem with this, please send me a copy. > > And now a bit of criticism (John Toebes, are you > listening?): Give us back our address register variables! My > favorite benchmark (a sieve) now runs about 15 secs instead > of 9 secs under LC3.10 for the first million prime numbers > (no output of course). At least offer an option the way > Aztec does (+r) if not using small data (= base relative). > And, by the way, I could not get the compiler to use A3 as > register, only A2, meaning I got only a single address > register left! And if I choose not to use "#pragma > libcall/syscall" it should be possible to use A6 as either a > register variable or the base register (now A4). There are a couple of points here to be answered: The compiler allows for 2 address register variables and 4 data register variables. Failure to do that is a bug and should be reported. I have successfully used that for many cases. As for A6, there are several issues to be looked at: 1) Under 3.10 it is possible to generate a CXERR 25 (not enough registers) when you allocate 3 pointer registers because the compiler has only 2 to calculate the expression with (the other 3 are already reserved) 2) 4.0 is doing better register tracking, so having an additional register free does allow it to keep temporaries around longer - more registers means it can not flush them to memory. In particular these temporaries are parts of address calculations that you only hint at in your code. 3) By reserving A4 constantly, the compiler allows you to freely mix code compiled with either model. 4) Benchmarks in general are not necessarily a good test of compiler performance (Dhrystones is a notable exception as it is quite unlike other benchmarks). Wesley Howe (Asm68k author) gained a 12% performance improvement with 4.0 over 3.10. A final note, in general REGISTER is just a hint to the compiler. As compiler technology advances and optimizers become more commonplace, you will want the compiler to assign registers only for the time period they are used. With the current scheme of things, you must assign the register for the entire procedure. Many times you would want to use a register only for a short portion of the subroutine and then reallocate it to another variable for the rest of the program. > In addition you should release documentation on the new > object format (library indexing). You did so in the > "read.me" to LC3.10 for the base relative addressing and > usage of a well documented standard object format has always > been the reason I preferred Lattice to Aztec (both are still > great compilers and if I need "#asm" I use Aztec of course). > The object format defined by MetaComCo had to be enhanced, > but then, please tell us about these improvements. We have every intention of releasing the documentation on the Library format. The doocument on it is quite long (probably too long for posting here), but I will make sure it is on the Lattice BBS for downoading. The reason we haven't published much about the format is that we want to make sure it is acceptable to Commodore. > > The preprocessor symbol "LATTICE_C" should be defined the > way Turbo C (gee, what's that?) does it (version number) in > addition to those (now undocumented) symbols (who wrote the > manual?). Actually we have been moving to less #defines automaticaly in the interest of moving toward ANSI compliance, but as always we are open to input. > And, by the way, "OMD" does not recognize "BCS". Yes, I noticed that too. This is quite funny as the compiler generates it all the time now. It is on the way to being fixed. > Goodbye for now, I hope this helped someone. > Ralph Babel, Falkenweg 3, D-6204 Taunusstein, West-Germany. It has been helpful to me. I certainly welcompe any input on the compiler or future directions we should pursue. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
ewhac@unicom.UUCP (Bols 'Leo Schwab' Ewhac) (11/07/87)
[ Please join me in welcoming my old haunt, College of Marin, to the USENET. ] In article <198@sas.UUCP> toebes@sas.UUCP (John Toebes) writes: >In article <789@rmi.UUCP>, kkaempf@rmi.UUCP (Klaus Kaempf) writes: >> "#pragma syscall" uses address 4 as library base pointer. >Actually what it does is load _AbsExecBase ($0004) into a register giving the >library base. This is exactly what you would do if you coded it in >Assembler. Ah! Okay, I misunderstood the original statement. I withdraw my previous alarmist posting. _-_-_-_ Old .signature used because my new one isn't on this machine. _-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."