tjhayko@THUNDER.LAKEHEADU.CA (05/29/90)
Welcome back to the net, Matt. I'm interested in what some of the features of you DICE C Compiler are. How does it compare with commerical compilers? or other Public Domain/Shareware offerings? What does it include in the package? ********************************************************** * Tom Hayko * only the Amiga /// * * tjhayko@thunder.lakeheadu.ca * (if only Commodore /// * * tjhayko@LUSUN.BITNET * knew that) \\\/// * * tjhayko@LAKEHEAD.BITNET * \XX/ * ********************************************************** QUIT
dillon@overload.UUCP (Matthew Dillon) (05/31/90)
>In article <9005290344.AA10362@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: > >Welcome back to the net, Matt. I'm interested in what some of the features of >you DICE C Compiler are. How does it compare with commerical compilers? or >other Public Domain/Shareware offerings? What does it include in the package? *FAST*, clean compilation is the main thing. The DICE system includes nearly everything required to generate an executable, editor (DME), front-end (DCC), preprocessor (DCPP), main-compiler (DC1), a minimal assembler (DAS), linker (DLINK), c.lib (+ source to c.lib), ANSI includes, all written by yours truely! I have even managed to write most of the time handling routines. You need to get amiga.lib and the 1.3 includes from commodore separately, at least until I get my redistribution license for that stuff. Or you can simply use the amiga.lib and 1.3 includes that comes with Lattice/Aztec if you have either of those compilers. As I say in the documentation, this is the first major release of DICE and it does not support everything yet... floating point and bit fields, for example, have not been implemented. On the otherhand, it's nearly 100% ANSI and all of DICE compiles itself (as well as DME, all of the UUCP1.06 distribution now, and everything else I'm doing). I.E., it is a real compiler that generates real code. It has a real nice UNIX CC-like front end (DCC), and since the front end knows it is loading DICE executables it searches the resident list itself to find the sub-programs (DCPP, DC1, DAS, DLINK). The end result is that there is no overhead running the sub-programs if they are resident. DICE supports residentability (and there are no restrictions on library calls since amiga.lib is made small-data-model). You can even declare a huge BSS array that causes BSS data to go over 64KBytes -- as long as it is the *last* declaration in the *last* module of your code and you do not use any constant-indexes that would go beyond the small-data 16 bit offset limit. The assembler and/or linker will catch any problems. The reason this works is because the linker, DLink, guarentees section ordering and the library code (c.lib) is compiled with different section names than the default AND the startup module (c.o) declares these alternate section names before the standard section names, thus guarenteeing that all library BSS declarations come before any user BSS declarations. This also means you only need one c.lib, ... not the 10 billion versions that come with Lattice and Aztec compilers. Oh, there are a few cases where you might need a large-data-only model version of c.lib, but only if you are doing something really esoteric. Also, there is only one c.o startup module and it handles both the resident and non-resident case. Resident code will startup nearly instantaniously because the startup code does not need to do any 32 bit data-data relocations, ever. The additional code required to support resident in c.o is miniscule. This is due to the fact that the compiler, when given the -r option, will generate special autoinit code *instead* of a normal 32 bit data-data reference for statically initialized data. I.E. something like this: short a; short *b = &a; /* a 32 bit relocation */ (no -r option) (with -r option) section bss,bss section bss,bss ds.w 0 ds.w 0 _a ds.b 2 _a ds.b 2 section data,data section data,data ds.w 0 ds.w 0 _b dc.l _a _b dc.l 0 section autoinit0,code lea _a(A4),A0 move.l A0,_b(A4) section text,code section text,code ... ... All autoinit sections are glued together at link time and called as a single subroutine from c.o, with a terminating (x.o) module at the end containing the single RTS. The DCC front end handles all of this for you. Autoinit sections also support the automatic openning and closing of certain system libraries (I only implemented a few but you can implement more) without the programmer having to lift a finger. E.G. a library module exists which declares a library base variable. If you reference that variable in your code but do NOT declare it, the library code module containing the declaration will be included along with autoinit code also defined in that module to open the library on startup and close it on _exit. If you *do* declare the library base variable then the library module is not included and you have to open and close the library yourself, so this feature is compatible with code that does it the normal way. Oh gee, almost forgot. I do have a special _autoinit keyword which you can apply to a subroutine that, guess what!, yup! calls that subroutine from c.o *before* _main(), allowing arbitrary init segments that get called simply due to their existance at link time and completely independant from all the rest of your code.... useful when you do not want the 'user' code to know about the module. DICE does not have registerized parameters or inline library calls. Frankly, anybody who appreciates such options also knows that simply optimizing one or two of his core routines will get better results anyway and these so called features only make the code less portable and more unreadable :-). Sorry, no stack checking option :-(. DICE will use D0/D1/A0/A1 for register variables whenever a code block or sub block { } does not contain subroutine calls. This usually results in DICE being able to substantially reduce the number of registers required to be saved and restored and to have more registers available for variables than would otherwise be usable. In many cases low level subroutines can completely eliminate the MOVEMs or at least reduce it to MOVEs. I think this is the major reason my code appears to run faster than Lattice (I don't know about Aztec, haven't compared those two yet) when running code compilable under both compilers (i.e. no floating point in the test). DICE also optimizes out LINK/UNLK if A5 is never referenced in the procedure *and* no subroutine calls are made from the procedure. DAS also optimizes Bxx-to-BRA (up to 20 levels), and uses short branches when possible, so many levels of loops, gotos, and/or if()s if()/else's get optimized nicely. You get source to the C library (written by me), though *not* source to the DICE binaries. I'm sending DICE to Tad tomorrow. That ought to do it for the synopsis. -Matt -- Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) (06/02/90)
In article <dillon.4040@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes:
DICE does not have registerized parameters or inline library calls.
Frankly, anybody who appreciates such options also knows that simply
optimizing one or two of his core routines will get better results
anyway and these so called features only make the code less portable
and more unreadable :-).
What - you expect us to do _all_ the work? :-)
Seriously, I find the registerized parameters/inline library call in
Lattice usefull; the first program I cut over to them picked up about
20% (not bad for just upgrading the program to the new compiler). The
only portability hit is having to provide/disable prototypes for
functions that want registerized parameters. Since I like prototypes
anyway, that's no big deal. More importantly, done right, they makes
doing shared libraries somewhat saner.
So, do you have any plans to add them to DICE?
Second question: Support for things other than the 68000? You didn't
mention it. Is it there?
Thanx,
<mike
--
Lather was thirty years old today, Mike Meyer
They took away all of his toys. mwm@relay.pa.dec.com
His mother sent newspaper clippings to him, decwrl!mwm
About his old friends who'd stopped being boys.dillon@overload.UUCP (Matthew Dillon) (06/06/90)
>In article <dillon.4040@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: > DICE does not have registerized parameters or inline library calls. >What - you expect us to do _all_ the work? :-) >Seriously, I find the registerized parameters/inline library call in >Lattice usefull; the first program I cut over to them picked up about >20% (not bad for just upgrading the program to the new compiler). The I do not plan to implement registerized parameters in the near future, but I would not worry too much about efficiency. DICE utilizes registers well, especially for low level subroutines (which is where the stack-args hit is most predominant). In many such cases DICE is able to remove both the LINK/UNLK *and* both MOVEMs completely and use scratch registers as register variables. DICE will put as many argument vars and local vars into registers as possible without requiring the register keyword, just like Lattice and Aztec. However, DICE is able to utilize more registers for register variables and generally makes better choices than either of the other two compilers. Needless to say, the performance gain you get from the above two items is much greater than you get with registerized parameters. >only portability hit is having to provide/disable prototypes for >functions that want registerized parameters. Since I like prototypes Its messy. It isn't just messy, it's *very* messy to implement. I intend to keep DICE lean, mean... and bug free. >Second question: Support for things other than the 68000? You didn't >mention it. Is it there? The commercial version will have an 020 option to utilize MUL*.L and DIV*.L, bit field stuff, and the scaling modes for array indexing. Also, the commercial version will implement a couple of things I do not intend to put in the shareware version (floating point, bit fields, structural returns). > Thanx, > <mike -Matt -- Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
jesup@cbmvax.commodore.com (Randell Jesup) (06/06/90)
In article <MWM.90Jun1135302@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) writes: >In article <dillon.4040@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: > > DICE does not have registerized parameters or inline library calls. > Frankly, anybody who appreciates such options also knows that simply > optimizing one or two of his core routines will get better results > anyway and these so called features only make the code less portable > and more unreadable :-). I find them QUITE useful. In fact, I'd guess dos would be at least 10-15+% bigger without them, and slower. >The >only portability hit is having to provide/disable prototypes for >functions that want registerized parameters. Since I like prototypes >anyway, that's no big deal. More importantly, done right, they makes >doing shared libraries somewhat saner. Everyone should use prototypes. Here's a useful set of defines if you need to switch back and forth, and perhaps to improve readability: #define ASM __asm #define REG(x) register __ ## x #define REGARGS __regargs '##' is the ANSI token-pasting operator. You would declare functions like this: long ASM foo (REG(d0) long mylong, REG(a0) struct bar *foobar); or long REGARGS foo (long mylong, struct bar *foobar); When you don't want registerized params, just define them to nothing. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
jjfeiler@chamber.caltech.edu (John Jay Feiler) (06/07/90)
Ok, I've played with DICE, it's great!!! But how soon will we see DICE++.... 1/2 ;-)
baggins@batserver.cs.uq.oz.au (Bill Segall) (06/07/90)
dillon@overload.UUCP (Matthew Dillon) writes: > The commercial version will have an 020 option to utilize MUL*.L and > DIV*.L, bit field stuff, and the scaling modes for array indexing. > Also, the commercial version will implement a couple of things I do not > intend to put in the shareware version (floating point, bit fields, > structural returns). What price range will the commercial version be? Do you have any idea about release dates? I need a *real* C compiler and I can't afford Lattice or Manx. Thanks, Bill Segall email: baggins@batserver.cs.uq.oz.au Ph: (07) 377 2956 The thing that astonished him was that cats should have two holes cut in their coat exactly at the place where their eyes are : Lichtenberg ========================================================================
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/07/90)
In article <3877@moondance.cs.uq.oz.au> baggins@batserver.cs.uq.oz.au writes: >dillon@overload.UUCP (Matthew Dillon) writes: > >> The commercial version will have an 020 option to utilize MUL*.L and >> DIV*.L, bit field stuff, and the scaling modes for array indexing. >> Also, the commercial version will implement a couple of things I do not >> intend to put in the shareware version (floating point, bit fields, >> structural returns). > >What price range will the commercial version be? Do you have any idea about >release dates? I need a *real* C compiler and I can't afford Lattice or Manx. I'm _thrilled_ to learn that Matt's compiler will come out in a commercial version (and, from a previous posting, a robust version), since Lattice and Manx desperately need a good example of what a bug free compiler looks like to force a little QA on them. However, don't let stuff like this drive you back to Turbo Pascal prices, Matt! I've paid (twice) $12,000 for compilers (one C, one Pascal); there isn't anything particularly outrageous about the cost of the existing C compilers. All the arguments in the games discussions about balancing cost against expenses that need recovering, expected sales volume, competition, cost of support, cost of materials and so on pertain even more to a compiler. Any hints as to who might bring distribute the commercial version, Matt? Just snooping! Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
dailey@cpsin2.uucp (Chris Dailey) (06/07/90)
In article <dillon.4156@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: (regarding DICE) > Also, the commercial version will implement a couple of things I do not > intend to put in the shareware version (floating point, bit fields, > structural returns). No floating point? Well, what's the 'poop' on the commercial version? Did I miss a previous reference to the commercial version? How much $$$? > -Matt -- /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) C oo dailey@cpsin1.cps.msu.edu (subliminal message-make WP5.1 for the Amiga) _( ^) "I am thankful for one leg. To limp is no disgrace -- / ~\ I may not be number one, but I can still run the race." -from B.C.
dailey@cpsin2.uucp (Chris Dailey) (06/07/90)
In article <1990Jun7.124404.16105@msuinfo.cl.msu.edu> dailey@cpsin2.uucp (Chris Dailey) writes:
Matt,
Oh, I'm sorry to waste more bandwith, but could you get most of it to
fit on a single disk? Those of us with floppies would love it if we
could have one disk as a data disk and the other as the C program disk.
Thanks,
--
/~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary)
C oo dailey@cpsin1.cps.msu.edu (subliminal message-make WP5.1 for the Amiga)
_( ^) "I am thankful for one leg. To limp is no disgrace --
/ ~\ I may not be number one, but I can still run the race." -from B.C.bluneski@pogo.WV.TEK.COM (Bob Luneski) (06/08/90)
In article <1990Jun7.112334.28159@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >I'm _thrilled_ to learn that Matt's compiler will come out in a commercial >version (and, from a previous posting, a robust version), since Lattice and >Manx desperately need a good example of what a bug free compiler looks like >to force a little QA on them. > I'm also VERY happy to see it as a commercial product. I believe there is room for three players in the Amiga C compiler game. However, there some significant deficincies that make it's current evolution totally unacceptable for serious commercial development purposes. Don't you think you should hold the: "it's the next best thing to sliced bread completely bug free" praise untill it's been released and let the market determine just how true that statement is? I belive you are also forgetting the value of post purchase user support which has not been demonstrated at the commercial level for DICE. A professional developer happy with Lattice, interested in Dice, but cautious, Bob Luneski
dillon@overload.UUCP (Matthew Dillon) (06/09/90)
>What price range will the commercial version be? Do you have any idea about >release dates? I need a *real* C compiler and I can't afford Lattice or Manx. I figure on the order of $150. The shareware version is $40, and I will offer an upgrade path from shareware->commercial for people who send in their $40 (i.e. $150-$40 = $110). THIS IS A GUESS. I have not decided yet. The commercial version will not be ready for 3 to 6 months, the main thing being bitfields. I've already got floating point working using the amiga libraires but fp will not be in the shareware version. I also need to do a lot of general fixing up & enhancement (like 020 instruction support), and fix any unimplemented items in the preprocessor (such as token pasting: ##), and generally make sure it compiles all my stuff as well as as much of GNU as I can get my hands on (GNU code is a good test). I expect to support the commercial and shareware versions on a parallel line and for shareware versions to come out more frequently. So far, there have been several bugs reported having to do with name space problems (e.g. an enum constant used as a structure or enum identifier, or a goto label id also used as a variable id), one in the preprocessor: "abcd\ efgh" (Though frankly people ought to use the ANSI "abcd" "efgh" constructor. The bug in the above is that DCPP currently includes the newline as part of the string which is wrong) One problem with the front-end: DCC aparently does not work well with ARP or WShell due to scanning the resident list itself for efficiency. The new DCC frontend will have a -f switch where it uses Execute() normally and, given -f, scans the resident list itself. There have been a few reported problems with the code generator producing incorrect code such as 'lea D0,A3' or similar code... I expected these to come up. All and all the problems are caught by either DC1 or DAS and do not make it through unnoticed. > Thanks, > > Bill Segall email: baggins@batserver.cs.uq.oz.au > Ph: (07) 377 2956 -Matt Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
janhen@kunivv1.sci.kun.nl (Jan Hendrikx) (06/11/90)
There is a bug in the ctype array carya. Only SPACE and TAB are qualified as being whitespace (isspace()). But NL, CR, VT and FF are also supposed to be whitespace, according to K&R2.
djh@dragon.metaphor.com (Dallas J. Hodgson) (06/12/90)
Matt, may I strongly suggest that before you officially release a -Commercial- compiler, that you run it through a C Test Verification Suite first. I'm assuming your compiler will be ANSI-compliant? Metaware has test suites available, as does at least one other company; I don't imagine they'll be cheap. Aztec & Lattice have a long enough history that users have flushed out a lot of bugs for them. Save yourself a lot of trouble and consider exercising your compiler on a Test Suite; I know Aztec bought one quite a while ago. +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+
gerry@dialogic.UUCP (Gerry Lachac) (06/13/90)
In article <1209@metaphor.Metaphor.COM> djh@dragon.metaphor.com (Dallas J. Hodgson) writes: > >Matt, may I strongly suggest that before you officially release a >-Commercial- compiler, that you run it through a C Test Verification Suite >first. I'm assuming your compiler will be ANSI-compliant? Metaware has test >suites available, as does at least one other company; I don't imagine >they'll be cheap. I second that motion. However, may I suggest using test suites that are already out as "freeware (sort of). I've seen a whole suite of tests for gcc and gcc++ (GNU's redistributable C compiler). C is C (one would hope) so those tests should work for DICE as well. -- uunet!dialogic!gerry | "Even a dead plant turns | Dialogic Corporation OR | over a new leaf | 300 Littleton Rd gerry@dialogic.UUCP | when the wind blows." | Parsippany, NJ 07054 | | (201)334-8450
aduncan@rhea.trl.oz.au (Allan Duncan) (06/14/90)
From article <dillon.4040@overload.UUCP>, by dillon@overload.UUCP (Matthew Dillon): [...] > As I say in the documentation, this is the first major release of DICE > and it does not support everything yet... floating point and bit ^^^^^^^^^^^^^^ > fields, for example, have not been implemented. On the otherhand, > it's nearly 100% ANSI and all of DICE compiles itself (as well as DME, > all of the UUCP1.06 distribution now, and everything else I'm doing). > I.E., it is a real compiler that generates real code. [...] When you get around to that, see if you can leave some expansion hooks in for complex arithmetic! You'd be the first C compiler on the block with that and have science and engineering types rushing to your door :-). Oh yeah, and a nice way of rounding float to int - I had to roll a kludge yesterday for it :- #define round(x) ((x)<0.0?(x)-0.0001:(x)+0.0001) I'm not about to start religious wars here, it's just that I wonder why the ANSI mob didn't provide for the capability to extend the type range of the basic arithmetic operators. Allan Duncan ACSnet a.duncan@trl.oz ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
dillon@overload.UUCP (Matthew Dillon) (07/04/90)
I've revised my thinking as to the distribution / shareware
registration / commercial version stuff. For the near future
registered ($40) shareware users will get DICE with as much as has been
implemented so far. The network distributions will be missing certain
features such as floating point and bit fields and maybe some keywords
such as __chip.
Currently I expect to get a reasonable registered ($40) release together
in a month that is sufficiently advanced from the unregistered version.
I will be holding requests for the registered ($40) version until I
get the appropriate licence from commodore to allow me to send a fully
self contained distribution.
Also, thanks to all of you who have sent in bug reports! Several small
bugs have been found in the c.lib and in the main compiler pass (so far
nothing not caught with an error message), and one problem with dlink
(linking in objects containing CHIP memory data segments). A few
problems have been found in the preprocessor associated with macro
recursion... has to do with dcpp doing macro replacement of symbols at
the wrong time which showed up compiling some GNU code. Also the
string construction:
"abcd\
efgh"
does not work properly ... the newline is kept in the string when it
is not supposed to be.
I would be interested in any comparisons of the size and speed of your
own code compiled under DICE verses compiled under other commercial
compilers (please send private email). I'm not really interesting in
benchmarks since I can do those myself (and they are generally
meaningless anyway for same-machine comparisons).
-Matt
--
Matthew Dillon uunet.uu.net!overload!dillon
891 Regal Rd.
Berkeley, Ca. 94708
USApepers@enme3.ucalgary.ca (Brad Pepers) (07/06/90)
I for one would be VERY interested in registering -IF- you could get a few
more bugs out. I tried two things on DICE as a test. The first was BYacc1.4.
The compile produced invalid code for the passing of argv, assert was
defined the wrong way around, and a few routines weren't available (mktemp,
getenv,abort). While I realize that this is the beginnings of a great c
compiler for the amiga, its not useable by me right now since I must fight
with it to get proper code.
The second test was A68k. With this one the compile died (error message
with impossible line number) and since I didn't want to hunt down the reason
I left it at that.
Best of luck with what is truely a promising product but I for one won't
pay for it until I can actually use it.
(GOD I hope I'm not coming through too strong - I just wanted to explain
some problems I've had and why I won't pay for DICE yet)
Brad Pepers