Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ki4pv.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!ucf-cs!ki4pv!tanner From: tanner@ki4pv.UUCP (Tanner Andrews) Newsgroups: net.unix-wizards Subject: Re: Need 286 Benchmark? Message-ID: <410@ki4pv.UUCP> Date: Tue, 13-Aug-85 11:35:21 EDT Article-I.D.: ki4pv.410 Posted: Tue Aug 13 11:35:21 1985 Date-Received: Tue, 20-Aug-85 05:33:44 EDT References: <525@brl-tgr.ARPA> Organization: CompuData South, DeLand Lines: 40 ] in above-referenced note, commentary is made about applications ] not developed on the intel advanced-elevator-controller-286 due ] to architectural ugliness. Having here one of the aforementioned chips, and being the developer of some huge code on these little monsters, I feel not only qualified to comment but compelled by the frustrations. Due to the problems of the segmentation, large (>64K in theory) arrays are impossible. Due to other bugs, the actual limit from malloc() is 32K. Large programs must be built using special compiler options with which no other machine in my experience is plagued; option is required for large (>64K code), and options to group code into segments are supplied though due to bugs they don't work (tnx microsoft). Building progs with the larger code option makes bigger code, as code pointers grow to 32 bits. Data pointers don't grow, which is a relief if it is necessary to manipulate data -- but the old scheme of stashing a general pointer into a (char *) no longer works! Sorry, k&r. There are lots of bugs associated with the unix/xenix and the c compiler and libraries on this machine, and many of them are the result of casual trust in the segmented architecture not to come along and give you a kick in the sensitive locations. Advice from a `286 user: buy a 68K. However, please note. Applications _are_ being developed on the miserable thing. In C; the C used is not changed to reflect any peculiarities of the '286. The compiler options are being used, of course; the Makefiles are thus different. The code is kept particularlyy "clean" so that it will compile and run under the '286 as well as other, more sane, architectures. There is also the problem of specifying segments to the debugger, and making sense of arguments passed to functions. I guess that has caused as much frustration as anything with the segmented architecture. --Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner