cmcmanis%pepper@Sun.COM (Chuck McManis) (11/11/88)
Somewhat commercial posting follows, I don't have any association with
Lattice other than they were the first compiler I used. I also have the
Manx compiler (3.6) and I like it as well. Manx is said to be reading
4.x of their compiler for release. We'll compare that when it comes out.
In the mean time, the compiler wars continue with ...
Another step taken forward in the Compiler Wars, Lattice 5.0 was released
Tuesday November 8th. Needless to say I've ordered the Update and will
give a more complete review in another message. Lattice has once again
"bundled" stuff with their compiler, now it is called the "Compiler Companion".
New 5.0 features from their list :
o Include source level debugger called "CodeProbe", it's supposed to
be like CodeView the Microsoft product. This is one of the most
anxiously awaited feature.
o Global Optimizer, which can, in theory, generate much smaller
executables since it watches the whole program for improvements
rather than just sections. A good test for global optimization
is the drystone program because a good global optimizer will
realize it doesn't "do" anything and optimized everything but
the printfs out of it :-).
o The Compiler Companion which is essentially a bunch of utilities
they used to sell separately like lmk (make), lse (editor),
cross reference utlity (cxref), and the old TMU package.
o And a facility for having the compiler generate prototype files
for you rather than walking through your code by hand.
o And "improvements" to the assembler to support the 68020 and
'881.
o Now in two manuals (I'm betting one is the old compiler companion
manual).
o Oh and the debugger has an AREXX port, and the compiler talks to
the Editor (moves the cursor to the next error etc). It looks
like they may have created an integrated compiler environment.
So it looks like quite a step forward. Updates range from $100 if you have
3.X to free if you bought or updated to 4.0 after July '88. Also they have
some deal where you can send them your Manx 3.4 or later compiler and $150
for their new compiler. This is actually cost effective if you haven't
purchased Manx's debugger yet. The 4.0 to 5.0 cost is $75. List price on
the compiler is $300. For more information contact Lattice, they are at
(312) 916-1600.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.peter@stca77.stc.oz (Peter Jeremy) (11/21/88)
In article <77037@sun.uucp> cmcmanis%pepper@Sun.COM (Chuck McManis) writes: >Another step taken forward in the Compiler Wars, Lattice 5.0 was released >Tuesday November 8th. Well, I received my update notice (with a glossy for C++) last Friday. That's not bad time to get from the US (they airlift them using a private company which probably helps). Before I plonk down my hard-earned money I would like to know a bit more about it. >New 5.0 features from their list : [ description of features removed ] The most obviously missing thing is an indication of hardware and software prerequisites. Can it run on a 1meg, 2 FD system, or does it need HD and/or more ram? (Yes, I know thats not a good development environment, but money is a bit tight at present). Will it run under 1.2 and/or 1.3? Another thing I would like to know, is what improvements they actually did to the compiler, and what changes they will make to your code. Also they didn't say how ANSIfied the new compiler is. When version 4 came out, the writeup was full of figures showing how much faster it was than 3.10 (and Manx). This seems missing (apart from a nicely vague "up to 30% faster"). Would someone (John Toebes maybe) like to post the list of enhancements and bug-fixes over 4.01, as well as some figures on how well it works. > A good test for global optimization > is the drystone program because a good global optimizer will > realize it doesn't "do" anything and optimized everything but > the printfs out of it :-). As an aside, this is only true of Dhrystone 1.x. The latest 2.1 which was posted in comp.arch a few months ago prevents this by splitting the benchmark into two files. It also uses the results of the variables it plays with (by printing them out at the end) to prevent this sort of tomfoolery. -- Peter Jeremy (VK2PJ) peter@stca77.stc.oz Alcatel-STC Australia ...!uunet!stca77.stc.oz!peter 41 Mandible St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015
bader+@andrew.cmu.edu (Miles Bader) (11/24/88)
peter@stca77.stc.oz (Peter Jeremy) writes: > The most obviously missing thing is an indication of hardware and software > prerequisites. Can it run on a 1meg, 2 FD system, or does it need HD and/or > more ram? (Yes, I know thats not a good development environment, but money is > a bit tight at present). Will it run under 1.2 and/or 1.3? Well, I'm running it right now on a 2floppy, 1 meg system. It works fine; I've rezzed all the passes, and use lot's of faccii buffers. I have the compiler passes, includes, & necessary libraries on [a very full] one disk. I generally have to exit the editor to compile & unrez everything to use the debugger. The biggest irritation in this setup is that they have moved the error messages to separate files, and they search the executable path to find these files. Besides being sort of ugly, they seem to search THE WHOLE PATH, even if the file is in the first directory. Because of this, I have to re-assign c: to ram or something, so it won't keep asking me to insert my workbench disk, 300 times per compile... > Another thing I would like to know, is what improvements they actually > did to the compiler, and what changes they will make to your code. Also > they didn't say how ANSIfied the new compiler is. The generated code seems a lot less stupid than 4.0. The biggest win I could see in the output is that it automatically promotes variables to register variables, and doesn't pop the stack after every function call, waiting until the last possible momement, and popping the stack for a whole bunch of function calls at once. The "global-optimizer" is not REALLY a global optimizer-- it only optimizes within a function [and it often looks like only within a basic-block, but that's just a guess based on some wierd output]. It doesn't produce perfect code, but it's pretty good. ANSI: They say that it has a full ansi preprocesser, string concatenation, supports void*, optional dummy parameter names in prototypes, const & volatile. I tested my previous gripe, that 4.0 didn't support ansi-style formal parameters, and 5.0 does indeed support them. The preprocessor now has #elif & defined(). There's some new startup files (besides c.o & cback.o): cres.o-- lets you make a "pure" program, that can be shared when resident, catch.o-- catches gurus and tries to do a stack dump to a file. There are also startups that combine the above behaviors. DEBUGGER: The debugger is REALLY NICE... It has separate windows for commands, registers, code (which can be c, asm, or interspersed c & the generated asm), and "watched" variables (which unfortunetly is only a memory dump). It can have breakpoints on both stack & data (although like dbx, data breakpoints supposedly slow down execution a lot) and single step over or into function calls. It knows about types & things, so they print out like you expect (so why don't they let you use t yped-printout for watched variables? I donoo). It basically has everything I've wanted so far (I'm used to dbx & gdb). The biggest problem with the debugger is that it can't deal with variables moved into registers by optimization, so you either have to look at the assembly code and see which register a variable is in (which isn't actually too hard, given that interspersed c & assembly on the screen), or compile with a high debugging option, and leave out the global optimizer pass. The latter will produce code that the debugger can handle well, but is not nearly as good code. I've found one bug in the debugger (the "where" command [in addition to not correctly printing the args for all the active calls] messes up some internal tables; but typing "where" again seems to fix it!?) OTHER STUFF: You get a whole bunch of utilities, lse-- a bad editor, lmk-- a make program, grep, diff, lprof & lstat -- a code profiler (yay!), cxref-- a c cross referencing program, files-- a less powerful analogue of the unix find command, touch, wc, tb-- a program that will print a stack backtrace from a file dumped by the catch.o startup file, and some other random utilities. You also get a library of the regexp routines from grep. The whole thing comes on 5 disks (4.0 came on 4 disks, did 3.0 com on 3?), with two thick three-ring binders of documentation. -Miles