cm@jet.uucp (colin manning) (04/09/91)
Good afternoon/afternoon/evening netters ! I have several questions concerning programming in 386 protected mode. Does anyone have any experience of either the Intel 386 C code builder, or the (significantly more expensive) Watcom C8.0/386. Any feelings for reliability, quality of support etc ? What produces the best code ? Or should I be thinking of something totally different ? The requirement does not necessarily need a DOS extender, just a protected mode environment, since the application will never have any need to use DOS facilities itself. Do any of the above or other 386 development tools available provide such a thing, or do you always need a DOS extender ? It is possible to do interrupt handling in protected mode with either of the above kits, or do they still hand all that on to the DOS extender ? Many thanks in advance, -- - Colin Manning, cm%jet.uucp@ukc.ac.uk (world) OR cm@jet.uucp (UK only) ------------------------------ Disclaimer: Please note that the above is a personal view and should not be construed as an official comment from the JET project.
dj@bragi.ctron.com (DJ Delorie) (04/10/91)
In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: >Does anyone have any experience of either the Intel 386 C code builder, >or the (significantly more expensive) Watcom C8.0/386. Any feelings >for reliability, quality of support etc ? What produces the best >code ? Or should I be thinking of something totally different ? I recently ported gnu C++ to 386/DOS protected mode. It should be posted on comp.binaries.ibm.pc soon-ish (it's big). The price is right and the compiler is well known to produce good code. As for support, you get the source code! For those with FTP access, it's in grape.ecs.clarkson.edu in ~ftp/pub/msdos/djgcc/... (get the `readme' first and read it). >The requirement does not necessarily need a DOS extender, just a >protected mode environment, since the application will never have any >need to use DOS facilities itself. Do any of the above or other 386 >development tools available provide such a thing, or do you always >need a DOS extender ? You always need a DOS extender at least to get it running. Mine runs the application in ring 0, so there's nothing stopping you from grabbing the IDT, GDT, PD, etc and never returning to the extender at all . . . >It is possible to do interrupt handling in protected mode with either >of the above kits, or do they still hand all that on to the DOS >extender ? Mine has no built-in facility for grabbing interrupts, but you can always do a LIDT instruction and change the interrupt vectors in assembler to point to interrupt handlers that run in 32-bit mode. DJ dj@ctron.com
wallyk@bicycle.WV.TEK.COM (Wally Kramer) (04/11/91)
In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: ... > Does anyone have any experience of ... the Intel 386 C code builder ... ? ... About 3 years ago I worked on a project using the iNtel 386 tools. To summarize, they are awful. It wasn't just bugs, but major architectural flaws. As for support, .... Want me to say it again? :-) The saleman showed up weekly however (we were literally across the street from the division of iNtel which developed it). No bug I knew of was fixed throughout the 5 month period. The ICE was just as bad. To provide a semi-balanced opinion, the project did complete successfully. I'd hope they've fixed the major shortcomings, but, as I said, there were some architectural flaws: - To produce an executable from object modules required at least two steps, a binder and a builder (I think that's what they were called); one of these was extremely slow, and used so much memory that the network could not be simultaneously loaded. The steps to do a test iteration: 1. modify source code 2. compile it 3. update libraries (on the net) 4. copy updated libraries to local disk 5. reboot machine without network loaded 6. run the binder 7. run the builder 8. reboot with the network loaded 9. copy the result to the net, where the ICE could download it 10. run the simulator. As I recall, for ~400k of executable code, this was a 2-3 hour process. - At the time, the object module format was "proprietary". No third party binders & builders. (Is this still true?) - The documentation was below average. Poorly organized, omitted details and useful examples at every turn. - The ICE searched its symbol table for every piece of the command line. They had omitted any "modern" technique for speeding this search up. I don't remember specifics now, but, for example, placing a breakpoint at procedure foo and running required something like this: go foo With our build, it would take something like 45 seconds for the command to be parsed and about 1/4 second to execute. (That's what I call *real time*!) ----- Wally Kramer contracted from Step Technology, Portland, Oregon 503 244 1239 wallyk@orca.wv.tek.com +1 503 685 2658
beaudoin@ireq-robot.hydro.qc.ca (Martin Beaudoin) (04/11/91)
In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: > Does anyone have any experience of ... the Intel 386 C code builder I'm currently working on a project based on a AT-Bus Intel iRMX III system. The tools I've got an that system to develop code are IC386, ASM386, LIB386, BND386, BLD386, MAP386, etc. They are a real pain to learn and a real pain to use. They are also quite slow. When I need to modify some of my code integrated in the kernel, I'm usually in for at least 15 to 20 minutes of compilation just to generated a 700k bootloadable file... The Intel hotline for iRMX and its associated software is usually quite good, but you have to be able to explain the nature of your problem accuratly, which is sometimes difficult because iRMX is not easy to master... -- Martin Beaudoin mbeaudoin@ireq-robot.hydro.qc.ca Institut de recherche d'Hydro-Quebec mbeaudoin@ireq-robot.uucp Varennes, QC, Canada J3X 1S1 +1 514 652-8136
hutch@hutch (Stephen Hutchison) (04/11/91)
In article <10568@orca.wv.tek.com> wallyk@orca.wv.tek.com (Wally Kramer) writes: >In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: >... >> Does anyone have any experience of ... the Intel 386 C code builder ... ? >... > >About 3 years ago I worked on a project using the iNtel 386 tools. >To summarize, they are awful. It wasn't just bugs, but major architectural >flaws. As for support, .... Want me to say it again? :-) [other opinions deleted ...] The Intel 386 Codebuilder is a new product. It isn't what you worked with 3 years ago. Further, the 386 tools are significantly improved over what you saw 3 years ago. 3 years is a long time in this industry, Tek's time-to-market notwithstanding. I'd discount Wally's experiences unless you are dealing with a toolset sold to you 3 years back. Hutch (another former tek employee, btw)
wallyk@bicycle.WV.TEK.COM (Wally Kramer) (04/12/91)
hutch@hutch (Stephen Hutchison) writes: >[quotes me] ... >>About 3 years ago I worked on a project using the iNtel 386 tools. >>To summarize, they are awful. It wasn't just bugs, but major architectural >>flaws. As for support, .... Want me to say it again? :-) >[other opinions deleted ...] > >The Intel 386 Codebuilder is a new product. It isn't what you worked with >3 years ago. Further, the 386 tools are significantly improved over what >you saw 3 years ago. Thank goodness. > 3 years is a long time in this industry, At the time it was a new product for a then-new chip: the 386. I wonder what the useful lifetime of a typical software product is? MSDOS 3.3 is what?... about 4 years old? On the other hand, Turbo C seems to improve significantly about once per year. The old versions were completely tolerable however. > Tek's >time-to-market notwithstanding. Is that an insult? (Check out my .signature for why it fails.) For both of my contracts with Tek I've been involved with development of projects for which the time to market is rather narrow. 6-10 months for h/w and s/w products--neither of them trivial and requiring a good deal of custom components. > I'd discount Wally's experiences unless >you are dealing with a toolset sold to you 3 years back. Agreed. But I'd think the timespan affected would extend up until about 1.5 years ago. When was the "386 Codebuilder" released? ----- Wally Kramer contracted from Step Technology, Portland, Oregon 503 244 1239 wallyk@orca.wv.tek.com +1 503 685 2658