mem@sii.UUCP (Mark Mallett) (10/25/85)
I also got my MIX C compiler a week or two ago and agree with all the positive things that have been said about it here. It seems to be an excellent buy for $39.95 (or $45 with COD)- it comes with a thick paperback-book manual with C tutorial, reference, and lots of examples (there are some errors in the examples so the proofreading may not have been great). The compiler can produce listing files. The linker supports libraries-- you manipulate a library by converting it to an ASCII form and editing it! The linker can deal with either the ASCII or binary form (it appears that the binary form has an awful lot of overhead in it, but no matter there). Multiple overlay areas are supported, which is nice on a CPM80 system. On the negative side: - the linker seems incredibly picky. If you don't give it the commands in the right sequence, you can get a fatal error message or, worse yet, your program simply won't work. - you can define multiple overlay regions in your program, but each region is a fixed size and must be big enough for the largest overlay you are going to put in there. I would much rather see a hierarchical overlay structure, where overlay boundaries depend on the definition of the higher-level overlay. But again, for $40 this is great. - The minimum program size seems to be about 24K. This is because the compiler generates intermediate code; an interpreter occupies the first 20K or so of every program. This interpreter does not have to be linked with the program, so the file size can be small, but in this case you have to have the runtime overlay hanging around on your disc in order to run your programs. - There is no mechanism for linking assembler programs to the C programs. There *is* a mechanism for calling assembler programs, though, if you want to load or initialize code into memory somewhere, you can call it. Kind of like the Atari notion of a BASIC-Assembler interface. - The compiler matches reserved words in either-case mode; you CAN NOT turn this off. That is, the reserved word "int" can be given as "int", "Int", "INT", etc. This is the only thing that I think they did really Wrong. I bought because I hoped that since it generates intermediate code, it would compile some large programs to fit into my CPM80 system better. I haven't proved or disproved this notion yet, but given the horrible code produced by the Aztec and Ecosoft compilers that I have, I don't doubt that there is a size threshold above which programs compiled with MIX will be smaller than with those others. All in all, it seems to be a great buy, especially if you don't care about speed. About the MIX editor: I'll restate what I said several months ago. MIX seems to have done a great job with this too, but (as with the compiler) they made one thing Wrong: the editor doesn't deal with control characters. Like formfeeds and tabs!! So for me, the editor is useless. The folks at MIX say they are going to fix this-- I hope so, because the editor looks really nice. Mark Mallett decvax!sii!mem or ittatc!sii!mem
kim@mips.UUCP (Kim DeVaughn) (11/07/85)
[ ... go ahead, eat my bits ... ] > - There is no mechanism for linking assembler programs to the C > programs. There *is* a mechanism for calling assembler programs, I talked to the MIX.C folk the other day on this very point. The person I spoke to told me that they would have a utility very soon (actually, he said "in a couple of weeks") to convert Intel/Microsoft .obj format files into something the MIX linker could handle; I *think* he said it would be able to go the other way also, but I may be mistaken on that. He suggested I call them back to check on availability in early November. The cost will be "nominal" (~$5.00, or so), I was told. I also asked if they would publish the object format they are using. He didn't seem to see the need for that (given the conversion utility), but thought that he might be able to make a 1 or 2 page description available if I really needed it (a nice, helpful attitude ... very refreshing!) He offered this information on an "undocumented feature" of MIX.C: "After searching CLIB.MIX, if there are still unresolved references, a library called LINKER.MIX will be automatically searched also." He said they also plan to come out with several other libraries in the future (and I noticed the names PLIB.MIX and BLIB.MIX in one area of linker.com that needs to be patched with debug to configure it for a hard-disk). I haven't used MIX.C too much yet ... mostly just a few experiments to verify that I had patched cc.com and linker.com correctly (they omitted some of the instructions on my copy, but have corrected that oversight by now). Anyway, I'm satisfied that I got my money's worth, and as I mentioned earlier, I like their "bedside manner" over the telephone, and their responsiveness to customer requests. I guess the only gripe I do have is having to patch the .com files to do the hard-disk configuration; an install program would be alot more "professional", and in this case, it would be a pretty simple piece of code. I really can't complain very loudly on this tho ... for $39.95, its a real bargin. Disclaimer: I have no connection with MIX Software Inc., except as a satisfied customer. /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 415-960-1200 USPS: MIPS Computer Systems Inc, 1330 Charleston Rd, Mt View, CA 94043
bright@dataioDataio.UUCP (Walter Bright) (11/11/85)
In article <218@mips.UUCP> kim@mips.UUCP (Kim DeVaughn) writes: >> - There is no mechanism for linking assembler programs to the C >> programs. There *is* a mechanism for calling assembler programs, >I talked to the MIX.C folk the other day on this very point. The person >I spoke to told me that they would have a utility very soon (actually, he >said "in a couple of weeks") to convert Intel/Microsoft .obj format files >into something the MIX linker could handle. I am constantly surprised why compiler vendors keep inventing their own .obj file formats. It complicates life for both the vendor and the customer. The vendor has to write a linker and librarian, and perpetually try to help people who want to link in assembler or Fortran modules. The customer has to continually deal with a 'kludge' and object file conversion programs. The Intel .obj format isn't a secret either, Intel publishes a spec for it (though I would vote it for the 'Most Obtuse Document' award).