c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) (10/19/87)
I am planning on purchasing a C compiler in the near future. I have been
using a friend's old Lattice 3.03 but I want a legitimate compiler for
development work. (On PD software, for now!)
Having gained little from the objective reviews ("Both are good systems...")
I am interested in religious statements from any owners of MANX and Lattice,
especially from those who have seen Lattice 4.0 in action. Unless the flame
is low, please mail such statements PRIVATELY. I know people enjoy
espousing the virtues of their favorite compilers, but few people enjoy
reading about them.
Particular questions:
-Does Manx really use a different object file format? Are there any
provisions for going back and forth between standard and Manx formats?
-What are the respective upgrade policies? Since Manx uses different
include files, how soon after the release of 1.3 can I expect the
new includes and libraries?
-What are the classes of source code incompatibility?
-Size of code? Speed of compilation? Provisions for LARGE programs?
(i.e. Make utility included, etc.) Scatter-loading? Overlays?
Assembler included? 68010/68020/68881 provisions in compiler and
assembler? Overviews of compiler options?
-How about the documentation? (Great flame category.)
There are probably some people who love writing replies to this sort of thing.
I hope to hear from you.
*&(Jonathan Dubman)cmcmanis%pepper@Sun.COM (Chuck McManis) (10/19/87)
In article <4443@zen.berkeley.edu> (Jonathan Dubman) writes: >Having gained little from the objective reviews ("Both are good systems...") >I am interested in religious statements from any owners of MANX and Lattice, >especially from those who have seen Lattice 4.0 in action. Unless the flame >is low, please mail such statements PRIVATELY. [Minimal flamage here, just the facts ] I own Lattice, (thats what I started with), have nothing but hearsay to report on 4.0 although they should get my Update card today so I expect my copy RSN. The bottom line : Manx is an excellent compiler for those who know C really well. Lattice is an excellent compiler for those who tend to make typos or don't know C as well, by virtue of its extensive diagnostics. If you make the statement "If I had wanted to Lint my program, I would have run Lint!" then you probably want Manx. > -Does Manx really use a different object file format? Are there any > provisions for going back and forth between standard and Manx formats? They did last time I checked but they could link with standard Amiga .o's anyway. > -What are the respective upgrade policies? Since Manx uses different > include files, how soon after the release of 1.3 can I expect the > new includes and libraries? Upgrade to 4.0 Lattice from 3.03 is $75, from 3.10 $45. It arrives nearly exactly 1 yr after the 3.10 upgrade. Brand spanking new (developers version) goes for $225. > -What are the classes of source code incompatibility? > -Size of code? Speed of compilation? Manx wins. > Provisions for LARGE programs? Lattice has never had a problem here, don't know about Manx. Be sure to reassign the QUAD: file to a a real disk if you need the memeory. (it defaults to RAM:) > (i.e. Make utility included, etc.) Manx comes with make, Lattice doesn't. I use the one on one of the Fish disks. > Scatter-loading? Overlays? As far as I know only Lattice does these, and on Overlays only in 4.0. > Assembler included? 68010/68020/68881 provisions in compiler and > assembler? Yes on both counts. In 4.0 Lattice claims to have a totally compatible Assembler (can use the C/A .i files). > -How about the documentation? (Great flame category.) Both do really well here. --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.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/20/87)
>In article <4443@zen.berkeley.edu> (Jonathan Dubman) writes: >Having gained little from the objective reviews ("Both are good systems...") >I am interested in religious statements from any owners of MANX and Lattice, >especially from those who have seen Lattice 4.0 in action. Unless the flame >is low, please mail such statements PRIVATELY. >[Minimal flamage here, just the facts ] > >I own Lattice, (thats what I started with), have nothing but hearsay to report >on 4.0 although they should get my Update card today so I expect my copy RSN. Here's some additions to Chuck's response to Jonathan's original message from one who owns Aztec. > -What are the classes of source code incompatibility? > -Size of code? Speed of compilation? I don't think it is an issue anymore. Lattice 4.0 is supposed to be as good (or better) as the current Aztec release, and the next aztec releaes is supposed to better, etc..... but they don't, or wont differ all that much as time moves along.... there is a theoretical limit. > Provisions for LARGE programs? *No* 68000 C compiler that I know of has problems with code/data size. Only IBM-PC compilers have such problems. >> Scatter-loading? Overlays? >As far as I know only Lattice does these, and on Overlays only in 4.0. Aztec supports scatter loading and overlays as of 3.4a >> Assembler included? 68010/68020/68881 provisions in compiler and >> assembler? >Yes on both counts. In 4.0 Lattice claims to have a totally compatible >Assembler (can use the C/A .i files). Aztec also... in fact, the C compiler produces assembly so an Aztec compilation second stage *is* the assembler. I don't know if Lattice has moved from their QUAD intermediate file format to an assembler as far as compilation goes. One thing I have gotten used to with Aztec C is the use of 'void *'.. meaning a pointer to anything. Does Lattice implement this? As far as the ever evolving C spec, both Lattice And Manx are moving along parallel paths. -Matt
papa@uscacsc.UUCP (Marco Papa) (10/20/87)
Manx C 3.40 supports both scatter-loading and overlays (though they call it differently). -- Marco Papa Felsina Software
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (10/21/87)
In article <31235@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: <In article <4443@zen.berkeley.edu> (Jonathan Dubman) writes: <>Having gained little from the objective reviews ("Both are good systems...") <>I am interested in religious statements from any owners of MANX and Lattice, <>especially from those who have seen Lattice 4.0 in action. Unless the flame <>is low, please mail such statements PRIVATELY. < <[Minimal flamage here, just the facts ] < <I own Lattice, (thats what I started with), have nothing but hearsay to report <on 4.0 although they should get my Update card today so I expect my copy RSN. Ditto. <The bottom line : < < Manx is an excellent compiler for those who know C really well. < < Lattice is an excellent compiler for those who tend to make typos or < don't know C as well, by virtue of its extensive diagnostics. If you < make the statement "If I had wanted to Lint my program, I would have < run Lint!" then you probably want Manx. Well put. If you never make mistakes, then Lattice doesn't have any advantages - or very few. However, it should be noted that Lattice follows the Unix compilers in reporting errors: filename, line #, error message all on one line. Manx outputs the source line, then a line with an "^" to indicate the character it was parsing when it found the error, then the message. Iterate the last two for lines with multiple errors. Since I found it getting the line # wrong in ~ 50% of the cases (hard to avoid in recursive descent compilers), this seemed to me more like a waste of precious screen space than anything useful. <> -What are the classes of source code incompatibility? Avoiding odd practices, it boils down to three: 1) What in the set of dpANS - K&R features has been implemented. 2) ATT or BSD library calls. 3) 32 vs. 16 bit ints. With the next release of each compiler (Manx 3.6(?) and Lattice 4.0), most of those should vanish. 3) Manx already supports both 16 and 32 bit ints, Lattice 4.0 will support both. 2) dpANS is going with ATT library calls, + some extras. Lattice 3.10 follows those, and Manx is supposed to be going that way. For now, Manx has BSD library calls. 1) The ones that were in v7 c are in both. The ones in current Unix pcc are in both. Lattice supports prototyping, Manx is supposed to in the near future. Of course, if you play games with the Manx pre-compiled .h files (Lattice 4.0 has those), you can get into all kinds of trouble. <> -Size of code? Speed of compilation? <Manx wins. Uh, Lattice wins for .o files, Manx for the final executeable. Lattice does a lot more work for you in the libraries. Manx is noticably faster (Manx 3.4a vs Lattice 3.10). <> Provisions for LARGE programs? As Matt pointed out elsewhere, if a 68K C compiler has problems with large code or data segments, you've got a badly broken compiler. On the other hand, if you mean working with programs with lots of source - enough to want to scatter it into multiple directories - then I think Lattice wins. Lattice follows the Unix compilers in putting the .o for a file in the current directory, even if the source is elsewhere. Manx will put the .o in the same directory as the source. This means my Unix habits don't work. The difference in error message formats also causes some problems with large programs. <> (i.e. Make utility included, etc.) < <Manx comes with make, Lattice doesn't. I use the one on one of the <Fish disks. Doesn't the high-end lattice package come with a Make? Since most of the utilities in that package are available PA, and the cost of the rest is less than the cost difference of the package, it doesn't make much sense. <> Scatter-loading? Overlays? < Scatter-loading is done by the DOS loader. You can turn it off to get smaller binaries and faster startup time. Manx may produce binaries in the "no scatter-load" format, but it'd surprise me. Overlays can be done with the stock metacomco linker (alink). It can be used instead of the linker supplied by lattice (blink), though the 4.0 blink overlays. Theoretically, you ought to be able to compile code with Manx, convert it's .o files to AmigaDOS style .o files, then blink them to get scatter loading and overlays. Someone who uses Manx regularly want to comment? <Yes on both counts. In 4.0 Lattice claims to have a totally compatible <Assembler (can use the C/A .i files). < <> -How about the documentation? (Great flame category.) < <Both do really well here. I disagree with Chuck. The Lattice manuals are excellent, but the Manx manuals have problems. Then again, I didn't have original docs, I had docs that had been through several levels of upgrade. Problems: The upgrades weren't page replacements, they were addenda to the manual section. This means you have to check the manual & each addenda to use it as a reference manual. The manual disagreed with itself in at least one place. The function index was broken into parts depending on where the function came from. Not a bad idea, but the Lattice tehnic of having all functions in a single area (with an index, of course), and labelling each function as to where it came from (ANSI, Lattice or Amiga) works much better. Chuck, which manual set do you have? Hopefully, Manx improved there manuals as much between 3.0 and 3.4 as Lattice did between 3.02 and 3.10. Likewise, does the Manx upgrade include a new manual (Lattice did, which was a good thing). Of course, the function index is only of minor importance. I avoid the Lattice functions, and use the RKM/autodocs/RAP for the Amiga functions. The ANSI stuff I know by heart :-). The important part of the manual is the discussion of how the compiler parts work. Manx has an excellent tutorial, and mediocre reference. Lattice has a good tutorial and reference. Hard to say which is better, except for the (*&*^ addenda in the Manx manual. The one thing you didn't ask about was bugs. There are far more bug reports about Manx than about Lattice on the net. There are more bug reports about Manx on the net than there are about Lattice on the Lattice support BBS! My experience with Manx has been that it's a buggier compiler (I've tripped over about 5 Lattice bugs, each in a different program, in 21 months. I've tripped over 3 Manx bugs, all in one program, in 1 month). There's also the question of support. Lattice does very well, with a BBS with 9600 baud modems available to registered users. The one time I found a serious bug, I called in to report it only to find the patch on the BBS. They are also good about admitting "whoops, we made a mistake" on some features, and providing patches to fix them. Someone wanna comment on how Manx does in this area? Anyways, I think the free market is working it's magic, and the two companies are making sure their next release is better than the competitions last release. The result is that the best compiler is the last one to release a new version. The remaining differences qualify as "religious." The one thing I do wish for is that some of the low-cost IBM-PC compiler people would produce an Amiga compiler! <mike -- It's been a hard day's night, Mike Meyer And I been working like a dog. mwm@berkeley.edu It's been a hard day's night, ucbvax!mwm I should be sleeping like a log. mwm@ucbjade.BITNET
jdow@gryphon.CTS.COM (Joanne Dow) (10/23/87)
Rather than quote the entire article (*L*O*N*G*) I'll just fill in a couple
blanks re Lattice with a couple Manx observations. (Both are nice packages.
Both have tremendous support on bix if you can afford it. John Toebes and
John Meissen of Lattice are no more nor less hard working than Jim Goodnow
of Manx.)
Lattice compilers since 3.10 have included lmk, their make utility, in the
high end version. This package also includes some other goodies noteworthy
among them Metascope debugger.
At the Lattice 4.0 vs Manx 3.4b (which I do not have) level you'll find
different mixes of terrific features for gaining speed. Lattice will support
something called #pragma LibCall. This ends up placing the library calls into
the executable as direct library calls rather than having them go through any
intermediary library functions. This can give you a noticable speed improvement.
On the other tentacle Manx 3.4b has inline support for the 68020/68881
available. This is very nice for programs that do a LOT of high accuracy
floating point math. (I tried to talk John and John into it over on bix;
but, that was not on the 4.0 adgenda. perhaps next rev. These guys - all
three of 'em - certainly don't quit! I, sitting at the consumer level, *L*O*V*E*
this level of competition. We have two nice compilers available and they keep
getting nicer.)
Regarding the manuals I find Lattice's much more readable than the Manx
manuals. (That and I get bothered by the "set" stuff I have to do with
Manx. Too many other things use something called "set" and I keep wondering
"Gee, which of these wonderful "set's" that I have is the right one? <SIGH>)
Anyway - I spend lots more time trying to figure out where what I need hides
in the Manx manual and addenda than I do in the Lattice Manual. (Kudos to the
Lattice Manual writer!)
Long enuf - bye!
--
<@_@>
BIX:jdow
INTERNET:jdow@gryphon.CTS.COM
UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow
Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was
better you left it in the bush with the other one.peter@sugar.UUCP (Peter da Silva) (10/24/87)
In article <31235@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In article <4443@zen.berkeley.edu> (Jonathan Dubman) writes: > >Having gained little from the objective reviews ("Both are good systems...") > >I am interested in religious statements from any owners of MANX and Lattice, > > [Minimal flamage here, just the facts ] > > Manx is an excellent compiler for those who know C really well. > > Lattice is an excellent compiler for those who tend to make typos or > don't know C as well, by virtue of its extensive diagnostics. If you > make the statement "If I had wanted to Lint my program, I would have > run Lint!" then you probably want Manx. Well, I have the opposite impression. I have used Lattice and Manx. I prefer Manx for speed and size, but I hate its obnoxiously lint-like diagnostics. If Lattice 4.0 has more disgnostics than Manx, it's probably got more than lint as well. Lattice 3.whatever was minimally noisy. Both do a crummy job of error recovery. The rule should be... "after an error, dump the current expression and resynch to the next semicolon or brace". Both lattice and Manx seem to EAT the next semicolon or brace, leading to scads of bogus nesting diagnostics further down the line. > > -Does Manx really use a different object file format? Are there any > > provisions for going back and forth between standard and Manx formats? > > They did last time I checked but they could link with standard Amiga .o's > anyway. Correct. This is a pain, especially since the Manx linker has smaller external identifiers. It's a lot faster than Alink, though. And you get an Assembler with Manx. Side note... both Lattice and Manx include the preprocessor in pass 1 of the compiler. This is bogus, since it leads to VERY poor diagnostics. > > -What are the classes of source code incompatibility? Manx uses a bogus "memory model" scheme to avoid having to do a good optimisation job. But even in their large model they're faster than Lattice. I always use large model myself... if I wanted a segmented architecture I would have gone with IBM. No smiley. > > Provision for LARGE programs. > Lattice has never had a problem here, don't know about Manx. Be sure to > reassign the QUAD: file to a a real disk if you need the memeory. (it > defaults to RAM:) On Manx you "set CCTEMP=RAM:". I find that I can use Manx much more effectively on a 512K machine with the temp files in RAM:, because the compiler is physically smaller. > > Scatter-loading? Overlays? > > As far as I know only Lattice does these, and on Overlays only in 4.0. Manx does scatter loading, either on a file, routine, or 8K chunk of routines basis. By default it doesn't scatter-load. This is probably bogus (though it does speed up loading). Manx has an excellent "overlay" scheme that actually caches segments in memory quite transparently. I think this may only work on the small models... I haven't used it. I don't tend to write programs that big yet. > > Assembler included? 68010/68020/68881 provisions in compiler and > > assembler? > > Yes on both counts. In 4.0 Lattice claims to have a totally compatible > Assembler (can use the C/A .i files). Does Lattice now ship the Assembler with the Compiler? They used to be seperate products. Manx also allows you to include assembly in 'C' programs with "#asm". Very useful. Of course Lattice is better supported by C=. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (10/24/87)
Hands up everyone who thinks my excessive use of bogus is bogus? And I haven't even re-read the Jargon file yet! (you can crosspost *this* one to comp.sys.peter.da.silva, but only if you get my name right). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
acphssrw@csun.UUCP (Stephen R. Walton) (10/24/87)
In article <5540@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: ><Manx wins. > >Uh, Lattice wins for .o files, Manx for the final executeable. Lattice >does a lot more work for you in the libraries. Manx is noticably >faster (Manx 3.4a vs Lattice 3.10). What does "lot more work" mean in this context? Just that the brain damaged Metacomco library format (really just a concatenation of object files) is more work than a real library? >[on the Manx utilities] Well, the Manx package comes with make, diff, grep, the debugger db (soon to be replaced by sdb, the symbolic/source debugger), the library program, and Z, the vi-like editor. This last may be worth it alone if you're a dyed-in-the wool vi'er. I know of no PA vi clones. >Scatter-loading is done by the DOS loader. You can turn it off to get >smaller binaries and faster startup time. Manx may produce binaries >in the "no scatter-load" format, but it'd surprise me. Be surprised. Manx produces non-scatter-loaded binaries by default, but provides options for 8K hunks and for each .o file in a separate hunk; this last is Lattice/alink's default, and probably fragments memory more than it makes good use of the fragments you've got. The Manx 3.4a linker overlays. It also will use AmigaDOS style .o files and libraries directly, no conversions needed (I've linked Manx files to the 1.2 Enhancer amiga.lib just fine). >I disagree with Chuck. The Lattice manuals are excellent, but the Manx >manuals have problems. I second all of Mike's complaints about the Manx docs. >The one thing you didn't ask about was bugs. There are far more bug >reports about Manx than about Lattice on the net. The Manx patch file which Jim Goodnow posted for 3.4a patched 3 count 'em 3 bugs for that compiler, plus a few in the libraries. 3.4b seems to be essentially bug free; at least, it passes the Thomas Plum veri- fication suite without troubles. >[favorable description of Lattice BBS support and bug fixes, then] >Someone wanna comment on how Manx does in this area? Not as well, I'm afraid. I finally cajoled Jim Goodnow into checking the Manx BBS regularly (on the East Coast, number in the front of the docs) which he does now. It is still only 1200 baud, I think. I have yet to get any mail announcing upgrades from Manx; I find out about them from Bix. Lattice and Manx both are well-represented there, incidentally. (Yes, Bix costs more than PC Pursuit, but you'd not spend more than a few cents a month reading only the Manx and/or Lattice groups.) Finally, I second Mike's comments about the free market. By year's end, or at the latest early next year, it may come down to the color of the documentation binders :-).
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/87)
>Manx uses a bogus "memory model" scheme to avoid having to do a good >optimisation job. But even in their large model they're faster than Lattice. >I always use large model myself... if I wanted a segmented architecture >I would have gone with IBM. No smiley. Not at all... you can think of it as: small/large data: do I want to use relative or absolute addresses small/large code: do I want to use pc-rel or absolute addresses relative addressing takes one word less than absolute addressing, thus causing a not-so-trivial speedup when accessing global/static variables. Referencing auto (stack) variables doesn't change since they are SP-relative anyway. So for something like ... my TEST: device, there is no difference since I have few global variables. Something like DME or SHELL, however, have *lots* of global variables. -Matt
peter@sugar.UUCP (Peter da Silva) (10/28/87)
Just a comment on the buddha nature of Manx. The old Manx compiler was so buggy as to be almost useless. I have not run into a bug in the current version of the compiler yet. On another note, I'll likely be having a look at the M2Amiga modula 2 compiler soon. From what I've seen of their demo disk it looks pretty damn good. Good enough to get a dedicated 'C' fiend like me to try it out. Would anyone like a review? If you can't wait for my review, it's on the shelves now. -- -- Disclaimer: one of the authors of M2Amiga is temporarily residing on this -- node. I have no other connection with the company. Back in my IBM-PC days -- before C= showed me the light I knew some of the people involved with a -- PC Modula compiler. They didn't convince me to even try a copy of the -- product out, so my opinion isn't totally compromised by this. Besides... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (10/30/87)
In article <8710262044.AA08743@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >Manx uses a bogus "memory model" scheme to avoid having to do a good > >optimisation job. But even in their large model they're faster than Lattice. > >I always use large model myself... if I wanted a segmented architecture > >I would have gone with IBM. No smiley. > > Not at all... you can think of it as: > > small/large data: do I want to use relative or absolute addresses > small/large code: do I want to use pc-rel or absolute addresses If they can't do it without me having to take special precautions to make my code compatible with the small models, I don't want to know about it. Neither of these models work well on the Amiga, since they prevent scatter loading. I'm sure it's largely a hangover from their IBM-PC compiler. After all, in the older releases they even went to the trouble of mapping the nice Amiga timestamp format into the gross IBM-PC format. > relative addressing takes one word less than absolute addressing, thus > causing a not-so-trivial speedup when accessing global/static > variables. Referencing auto (stack) variables doesn't change since > they are SP-relative anyway. So they should use relative addressing for data/code that they know to be local to the module, but still use 32-bit pointers for indirection to maintain compatibility. The programmer should not have to know about it. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/31/87)
>> small/large data: do I want to use relative or absolute addresses >> small/large code: do I want to use pc-rel or absolute addresses > >If they can't do it without me having to take special precautions to make >my code compatible with the small models, I don't want to know about >it. Neither of these models work well on the Amiga, since they prevent scatter >loading. I'm sure it's largely a hangover from their IBM-PC compiler. After all, >in the older releases they even went to the trouble of mapping the nice Amiga >timestamp format into the gross IBM-PC format. Well excuuuuuse me. I would like to point out that not all of us "don't want to know about it". small/large code model aside, being able to specify the data model is extremely important in many applications. The trade off here is speed verses setup requirements. When I'm writing interrupt, library, or device code, I don't want to have to setup A4 for relative addressing, so I use the large data model. When I'm writing an application, I usually use the small data model for compact code and speed. >So they should use relative addressing for data/code that they know to be local >to the module, but still use 32-bit pointers for indirection to maintain >compatibility. The programmer should not have to know about it. If you don't want to deal with it, then don't. Get rid of your small code/data libraries and always use large code/data ... then you really don't have to know about it. In fact, since you "don't want to know about it", I guess that means you won't ever be writing C interfaces to Interrupts, Devices, or libraries. In that case, you can simply use the small data model (gee, look ma, I don't have to specify any options for that!), and forget about it, not deal with it, and "don't want to know about it". -Matt
peter@sugar.UUCP (Peter da Silva) (11/05/87)
> >So they should use relative addressing for data/code that they know to be local > >to the module, but still use 32-bit pointers for indirection to maintain > >compatibility. The programmer should not have to know about it. > > In fact, since you "don't want to know about it", > I guess that means you won't ever be writing C interfaces to Interrupts, > Devices, or libraries. In that case, you can simply use the small data > model (gee, look ma, I don't have to specify any options for that!), and > forget about it, not deal with it, and "don't want to know about it". > > -Matt You have things backwards. You're making a couple of assumptions that are probably not tenable. First of all, you're assuming that the compiler can't be smart enough to use the appropriate models when needed. That's not even the case on the IBM-PC. Sure, pretty much everyone has decided to accept memory models for 'C' compilers, but it's clearly not impossible. PL/M does a marvellous job of making the brain-damaged architecture of the 8086 family invisible. Microsoft is gradually improving mixed-model handling in their 'C' compiler, by the way. The 68000 has a much better architecture. Aztec has done a better job of "mixing models" on the 68000 than on the 8086, and with less time spent doing it. Their first Amiga compiler was pretty obviously as close to a straight port of the IBM-PC one as they could manage. They're getting better. When I can say "OpenLibrary("intuition.library", 33)" and have it use a 32-bit int for the argument (33), but still call "printf("%06d", i)" and pass 16 bits they'll have arrived. The second assumption is that the compiler should be designed to make the hard jobs easy, while making the easy jobs harder. One of the things you should always do is make the easy stuff easy. The hard stuff will always be hard. I mean, look at the reception your sample drivers are getting. Most people spend more time making calls to intuition.library than intercepting message packets. Even you do. Shouldn't that be made easier? One thing you got right... I'm going to be spending a lot more of my time working on getting the user interface of my code right than turning it into a library. Thanks for the code... I've never been a fan of reinventing the wheel (so long as it's not square). Boy, I'll be glad when Aztec goes to full ANSI with function prototyping and this "memory model" nonsense can be tossed out. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.