Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!news.nobody.at!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.arch Subject: Re: 80286 protected mode Date: Sun, 5 Jan 2025 21:49:20 -0000 (UTC) Organization: To protect and to server Message-ID: References: <2024Oct3.113903@mips.complang.tuwien.ac.at> <2024Oct4.193007@mips.complang.tuwien.ac.at> <2024Oct6.150415@mips.complang.tuwien.ac.at> <2025Jan3.093849@mips.complang.tuwien.ac.at> <2025Jan5.121028@mips.complang.tuwien.ac.at> Injection-Date: Sun, 5 Jan 2025 21:49:20 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="916741"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Bytes: 21432 Lines: 405 Anton Ertl wrote: > antispam@fricas.org (Waldek Hebisch) writes: >>Anton Ertl wrote: >>> antispam@fricas.org (Waldek Hebisch) writes: >>>>From my point of view main drawbacks of 286 is poor support for >>>>large arrays and problem for Lisp-like system which have a lot >>>>of small data structures and traverse then via pointers. >>> >>> Yes. In the first case the segments are too small, in the latter case >>> there are too few segments (if you have one segment per object). >> >>In the second case one can pack several objects into single >>segment, so except for loct security properties this is not >>a big problem. > > If you go that way, you lose all the benefits of segments, and run > into the "segments too small" problem. Which you then want to > circumvent by using segment and offset in your addressing of the small > data structures, which leads to: > >>But there is a lot of loading segment registers >>and slow loading is a problem. > > ... >>>>Using 16-bit offsets for jumps inside procedure and >>>>segment-offset pair for calls is likely to lead to better >>>>or similar performance as purely 32-bit machine. >>> >>> With the 80286's segments and their slowness, that is very doubtful. >>> The 8086 has branches with 8-bit offsets and branches and calls with >>> 16-bit offsets. The 386 in 32-bit mode has branches with 8-bit >>> offsets and branches and calls with 32-bit offsets; if 16-bit offsets >>> for branches would be useful enough for performance, they could >>> instead have designed the longer branch length to be 16 bits, and >>> maybe a prefix for 32-bit branch offsets. >> >>At that time Intel apparently wanted to avoid having too many >>instructions. > > Looking in my Pentium manual, the section on CALL has a 20 lines for > "call intersegment", "call gate" (with priviledge variants) and "call > to task" instructions, 10 of which probably already existed on the 286 > (compared to 2 lines for "call near" instructions that existed on the > 286), and the "Operation" section (the specification in pseudocode) > consumes about 4 pages, followed by a 1.5 page "Description" section. > > 9 of these 10 far call variants deal with protected-mode things, so > Intel obviously had no qualms about adding instruction variants. If > they instead had no protected mode, but some 32-bit support, including > the near call with 32-bit offset that I suggest, that would have > reduced the number of instruction variants. I wrote "instructions". Intel clearly used modes and variants, but different call would lead to new opcode. >>> I used Xenix on a 286 in 1986 or 1987; my impression is that programs >>> were limited to 64KB code and 64KB data size, exactly the PDP-11 model >>> you denounce. >> >>Maybe. I have seen many cases where sofware essentiallt "wastes" >>good things offered by hardware. > > Which "good things offered by hardware" do you see "wasted" by this > usage in Xenix? Medimu mode and shared segments. Plus escape for programs needing bigger memory (traditional Unix programs by neccesity fit in 64kB limits). > To me this seems to be the only workable way to use > the 286 protected mode. Ok, the medium model (near data, far code) > may also have been somewhat workable, but looking at the cycle counts > for the protected-mode far calls on the Pentium (and on the 286 they > were probably even more costly), which start at 22 cycles for a "call > gate, same priviledge" (compared to 1 cycle on the Pentium for a > direct call near), one would strongly prefer the small model. I have found instruction list on the web which claims 26 + m cycles where m in "length of next instruction" (whatever that means) for protected mode call using segement. Real mode call using segement is 13 + m cycles. Near call call is 7 + m cycles. Intel clearly expected that segment-changing calls are infrequent. AFAICS this was better than system conventions on IBM mainframes where "standard" call normally called memory allocation function to allocate stack frame. I do not have data for VAX handy, but VAX calls were quite complex, so probably also not fast. And modern data at least partially confirms Intel beliefs. When AMD introduced 64-bit mode thay also introduced complex calling convention intended to optimize speed of calls. Later there was a paper by Intel folks essentially claiming that this calling convention does not matter: C compilers inline small routines, so cost of calls relatively to other things is quite small. I think that what was inlined in 2010 would be called using near calls in 1982. >>> Every successful software used direct access to hardware because of >>> performance; the rest waned. Using BIOS calls was just too slow. >>> Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from >>> writing directly to video. >> >>For most early graphic cards direct screen access could be allowed >>just by allocating appropriate segment. And most non-games >>could gain good performance with better system interface. >>I think that variaty of tricks used in games and their >>popularity made protected mode system much less appealing >>to vendors. And that discouraged work on better interfaces >>for non-games. > > MicroSoft and IBM invested lots of work in a 286 protected-mode > interface: OS/2 1.x. It was limited to the 286 at the insistence of > IBM, even though work started in August 1985, when they already knew > that the 386 was coming soon. OS/2 1.0 was released in April 1987, > 1.5 years after the 386. > > OS/2 1.x flopped, and by the time OS/2 was adjusted to the 386, it was > too late, so the 286 killed OS/2; here we have a case of a software > project being death-marched by tying itself to "good things offered by > hardware" (except that Microsoft defected from the death march after a > few years). > > Meanwhile, Microsoft introduced Windows/386 in September 1987 (in > addition to the base (8086) variant of Windows 2.0, which was released > in December 1987), which used 386 protected mode and virtual 8086 mode > (which was missing in the "brain-damaged" (Bill Gates) 286). So > Windows completely ignored 286 protected mode. Windows eventually > became a big success. What I recall is a bit different. IIRC first successful version of Windows, that is Windows 3.0 had 3 modes of operation: 8086 compatible, 286 protected mode and 386 protected mode. Only later Microsoft dropped requirement for 8086 compatiblity. I think still later it dropped 286 support. Windows 95 was supposed to be 32-bit, but contained quite a lot of 16-bit code. IIRC system interface to Windows 3.0 and 3.1 was 16-bit and only later Microsoft released extention allowing 32-bit system calls. I have no information about Windows internals except for some public statements by Microsoft and other people, but I think it reasonable to assume that Windows was actually a succesful example of 8086/286/386 compatibility. That is their 16 bit code could use real mode segmentation or protected mode segmentation the later both for 286 and 386. For 32-bit version they added translation layer to transform arguments between 16-bit world and 32-bit world. It is possible that this translation layer involved a lot of effort. IIUC DEC when porting VMS to Alpha essentially gave up using 32-bit pointers as main interface. Anyway, it seems that Windows was at least as tied to 286 as OS/2 when it became sucessful and dropped 286 support later. And for long time after dropping 286 support Windows massively used 16-bit segments. > Also, Microsoft started NT OS/2 in November 1988 to target the 386 > while IBM was still working on 286 OS/2. Eventually Microsoft and IBM > parted ways, NT OS/2 became Windows NT, which is the starting point of > all remaining Windowses from Windows XP onwards. > > Xenix, apart from OS/2 the only other notable protected-mode OS for > the 286, was ported to the 386 in 1987, after SCO secured "knowledge > from Microsoft insiders that Microsoft was no longer developing > Xenix", so SCO (or Microsoft) might have done it even earlier if the > commercial situation had been less muddled; in any case, Xenix jumped > the 286 ship ASAP. > > The verdict is: The only good use of the 286 is as a faster 8086; > small memory model multi-tasking use is possible, but the 64KB > segments are so limiting that everybody who understood software either > decided to skip this twist (MicroSoft, except on their OS/2 death > march), or jumped ship ASAP (SCO). As I mentioned above I do not believe your claim about Microsoft. There were DOS-extenders which allowed use of 286 protected mode under DOS. They were used by several software vendors. Clearly, programming for flat 32-bit mode is easier and on software market that matters more than other factors. I think that 286 protected mode is good for its intended use, that is protected multitasking systems having more than 64 kB but less than say 4 MB. Of course, if you have a lot of hardware resources, than 32-bit system using paging may be easier to create. Also, speed is tricky: on 486 (and possibly 386) hardware task switch was easy to use, but slower than tuned purely software ========== REMAINDER OF ARTICLE TRUNCATED ==========