ONM64%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen) (02/15/89)
> From: Andy Tanenbaum <ast@CS.VU.NL> > Subject: Re: POSIX and the future of MINIX C > > In article <552@eecea.eece.ksu.edu> hardin@eecea.eece.ksu.edu (David Hardin)> > writes: > >So, in other words, an ANSI Standard C is strongly recommended. Is an ANSI> > >C planned for MINIX 2.0? If so, will the compiler still use EM > No. We have one, but it is too big for the PC. I'll have to stick with the> > current compiler. It does use EM, as do all our other compilers, however.> > > > Andy Tanenbaum (ast@cs.vu.nl) That's just once too much to take. I really am unable to see why Minix/PC can't support large Applications in the same way that Minix/ST does. As I see it, Minix/ST understands the file format of TOS (.PRG files), especially the relocation info. It does have some performance problems during a fork, but that's better than nothing. Well guys, MS-DOS also has a format for large files with relocation info (.EXE), why not use it? Since Minix/ST seems to have no problems at all with this scheme, I do not understand why we don't use it on the PCs. Maybe I should have titled this with "flame" ... Kai Disclaimer: This was written by my computer, not by me, so blame him for any faults.
hcj@lzaz.ATT.COM (HC Johnson) (02/15/89)
In article <8752@louie.udel.EDU>, ONM64%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen) writes: > > That's just once too much to take. I really am unable to see why > Minix/PC can't support large Applications in the same way that > Minix/ST does. > Kai somewhat misses the mark here. The beauty of MINIX/pc is that which the partitions less than 64 KB, the xx86 microprocessors are true virtual memory machines. MINIX took this and made a neet UNIX(r) look alike. It would even be possible to add swapping to it! The Atari version had to handle the problem of glueing each processes into memory at a fixed location. This is expensive, in lost space, and in S L O W switching between parent and child (before an exec occurs). The Atari ST makes up for this somewhat by often having >= 1 MEG of memory. I must admit, that I have an ATARI, and would have been really peaved if the programs were limited to 64 K. But then, the libc screws up all over limiting us to 32 or 64K activities. Ultimately, the next unsupported port of MINIX/pc will be to a PC with more memory and use the ATARI version as the porting base. I would suspect that AST may shed a small tear, tho, if this were done. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
clutx.clarkson.edu (Jason Coughlin,221 Rey,,) (02/16/89)
From article <415@lzaz.ATT.COM>, by hcj@lzaz.ATT.COM (HC Johnson): > In article <8752@louie.udel.EDU>, ONM64%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen) writes: >> >> That's just once too much to take. I really am unable to see why >> Minix/PC can't support large Applications in the same way that >> Minix/ST does. >> > Kai somewhat misses the mark here. > The beauty of MINIX/pc is that which the partitions less than 64 KB, the > xx86 microprocessors are true virtual memory machines. MINIX took this > and made a neet UNIX(r) look alike. It would even be possible to add > swapping to it! > Who cares about swapping on the PC? I mean it would be neat, but it would be SLOW (even ast said that the original had swapping but he took it out because it was ungoodly slow). However, the 64k limit is a SERIOUS limit! It would be nice to be able to write some good interpreters for Minix like a LISP interpreter, ISETL interpreter, etc. But I'd love to see someone squeeze a functional LISP or ISETL into 64k. > Ultimately, the next unsupported port of MINIX/pc will be to a PC with more > memory and use the ATARI version as the porting base. I would suspect > that AST may shed a small tear, tho, if this were done. Why should he shed a tear? Minix would be much more useful if applications could be >64k. More usefulness means even more users!! More users means (more money) more applications!! Actually, I think the point of Minix has changed. It used to be a teaching OS, but it's fastly turning into a real OS (as evidenced with version 1.3 which is "self-supporting"). Any real OS on a machine needs to be able to handle the resources of the machine and I don't think 64k is even close to the resources of the PC. I'm no engineer, but can't the PC address 1 meg? Would it be difficult to change Minix to use this much space? Since it isn't Messy-Dos, could it address 1 meg without those funny little LIM boards? -- Jason Coughlin ( jk0@clutx.clarkson.edu , jk0@clutx )
jds@mimsy.UUCP (James da Silva) (02/16/89)
In article <2485@sun.soe.clarkson.edu> jk0@sun.soe!clutx.clarkson.edu.UUCP writes: > Who cares about swapping on the PC? I mean it would be neat, but it >would be SLOW (even ast said that the original had swapping but he took it out >because it was ungoodly slow). I believe his original version swapped to floppies! Swapping to a decent hard disk would not be that painful. It would be slow, but not SLOW. >From article <415@lzaz.ATT.COM>, by hcj@lzaz.ATT.COM (HC Johnson): >> Ultimately, the next unsupported port of MINIX/pc will be to a PC with more >> memory and use the ATARI version as the porting base. I would suspect >> that AST may shed a small tear, tho, if this were done. > > Why should he shed a tear? Minix would be much more useful if >applications could be >64k. More usefulness means even more users!! More >users means (more money) more applications!! I'm sure that the marketing folk at Prentice Hall would agree with you, but I don't know that Dr. "Small is Beautiful" Tanenbaum would. Keeping the process space limited to 64k each for Instructions and Data allowed for a very clean design. > Actually, I think the point of Minix has changed. It used to be >a teaching OS, but it's fastly turning into a real OS (as evidenced with >version 1.3 which is "self-supporting"). Eh? Version 1.1 was "self-supporting", if by that you mean that it could serve as its own development environment. Still, I agree with you that Minix is now perceived as much more than just a teaching OS. > I'm no engineer, but can't the PC address 1 meg? Yes. >Would it be difficult to change Minix to use this much space? Minix does use all the memory in the machine. I presume you mean allowing a user program to access more than one code or data segment. It would be messy. Applications that use multiple segments under DOS are relocated at loading time, and are henceforth nailed down in memory. This makes it difficult to implement the Unix fork() system call. Of course, the ST people had the same problem, and their solution could be used on the PC as well. And it probably will be done by someone. Here's a possible evolutionary path for Minix: PC Minix (small model) --> 286 Minix --> 386 Minix --> VM Minix (paging) \ (386, 680x0 w/MMU) \ v ST Minix (fork hack) --> Applications PC Minix ("large" model) You take the low road, I'll take the high road... :-) :-) ;^} > Since it isn't Messy-Dos,could it address 1 meg without those funny > little LIM boards? DOS can address 1 meg without LIM boards, but IBM reserved the upper 384k for the ROM BIOS (and BASIC) and for use by expansion boards; for example, a CGA board which uses RAM starting at 0xB8000 for the screen. DOS applications can access this RAM directly. The 640k limitation is for general-purpose system RAM in the machine; it's not an addressing limitation. Since this is a limitation of the PC design, not of DOS, Minix must live with it as well. >-- >Jason Coughlin >( jk0@clutx.clarkson.edu , jk0@clutx ) Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
Leisner.Henr@xerox.com (marty) (02/16/89)
Once again, the Minix-PC memory models raises it's ugly face. Without even mentioning the effort required to write a more complicated 80x86 C compiler which can support near and far data types, all of Minix runs on the implicit assumption all message data is in the data segment. I don't like it, but that's the way it is. Without doing much modification to the a.out header structure, I wanted to define a large data model which would allow: <= 64 K text <= 64 K data <= 64 K stack infinite (well, almost) number of 64K additional segments. Assuming we have some way of memory management subroutines and a new, improved malloc for this large data model (something similar to the way 286/unix works) the operating system has to run with 32 bit virtual addresses -- there is an implicit assumption in Minix that messages are addressed in the data segment and 16 bit pointers are used. Would the above architecture allow more complicated programs? It seems with a decent C comiler, 64k of text is enough for a lot. Also, the above architecture would allow support for: 1) shared memory segments 2) embedding strings in the text segment On protected mode 286 machines, the stack could also grow dynamically up to 64k. In addition, protected mode implementation can give individual processes huge amounts of heap space (provided there is enough ram) without resorting to swapping. In addition, the memory manager/kernel interface has to be rearchitected, along with how memory manager information is encoded (right now we have NR_SEGS in const.h). I'm not sure the changes necessary to fully support the 8086 family is worth it. On a 32 bit 68xxx or 32bit 386 version, all these problems go away. I suppose due to the size of the market, the Ms/Dos compiler vendors have a lot of incentive to make the Intel architecture do more. Does anyone have a copy of PC-Minix which uses 32bit pointers within the operating system? I looked at it and felt it would cause distributed changes to the whole system -- I never got around to it. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
hcj@lzaz.ATT.COM (HC Johnson) (02/16/89)
In article <2485@sun.soe.clarkson.edu>, jk0@sun.soe!clutx.clarkson.edu (Jason Coughlin,221 Rey,,) writes: > I'm no engineer, but can't the PC address 1 meg? Would it be > difficult to change Minix to use this much space? Since it isn't Messy-Dos, > could it address 1 meg without those funny little LIM boards? Ok, for the non engineers, heres the low down. 1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB. There simply is no such machine operation. Microsoft added the ability to there C compiler output by adding 'far' pointers that basically pull 2 16 bit addresses from memory (segment:offset) and access one byte/word with the effective address. Slow, Clumsey, but the only way to do it. 2. the .exe format allows for text, data, or both to exceed 64K, by finishing the relocation to physical address when the program is loaded. This is the same idea as the ATARI ST uses when it loads. 3. Extened (or is it expanded) memory uses a window in the address space of the machine to access more memory. This is the only scheme on the 8088/8086. While useful for data bases, and other dedicated programs it a real mess for loading programs into. 4. the 80286 supports expanded(or is is extended) memory that addressable when running in protected mode. This paging mode was invented by someone who hated programmers. Its use in MINIX will take much patience! The bottom line is that: A. only the base 640K is readily useable. But it is available. B. A program can exceed 64 K only by using the Microsoft extensions. A MINIX would need to create Microsoft C 5.1 to have a CC command. C. Beyound that, the port from the Atari ST base should be straight forward. Maybe someone with a PC and ATARI ST will buy both MINIX versions and do the port before Easter as Penance. Good Luck. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
Chizmadia@dockmaster.arpa (David M Chizmadia) (02/17/89)
> Why should he shed a tear? Minix would be much more useful if > applications could be >64k. More usefulness means even more > users!! More users means (more money) more applications!! > > Actually, I think the point of Minix has changed. It used to be > a teaching OS, but it's fastly turning into a real OS (as > evidenced with version 1.3 which is "self-supporting"). Any > real OS on a machine needs to be able to handle the resources of > the machine and I don't think 64k is even close to the resources > of the PC. > Actually, as far as Andy is probably concerned, the point of MINIX hasn't changed. He still seems to want it to be small enough to be understandable, so that it can be used in the classroom as an example of how an OS manages a computer's resources. What has changed is the expectation of the most vocal group a contributors to this newsgroup. Having gotten psyched for GNU and never seen it, they've jumped on minix as the most readily and lowest cost realware and started trying to change it into GNU (ie. "all the world's a VM"). Personally, I like minix and the philosophy behind it - keep the base system small and understandable and break the applications into easily understandable and logically simple elements. The only place that I'd like Andy to reconsider the basic design of minix is in the way it handles dynamic memory allocation - specifically, I'd like to have the ability to dynamically request more than one segment of memory at a time for my current process. This would allow large data spaces (which are perfectly reasonable for things like editors, spreadsheets, comm programs, and databases - you know, the stuff that makes the computer useful :-) but still force the designer to keep the programs themselves small and to the point. It also keeps the compiler relatively simple since the code generator stays the same and just the pointer size changes. Of course I'm biased, since most of these features are supported by the 286 AT hardware - which is what I'd like to see MINIX run on efficiently. > I'm no engineer, but can't the PC address 1 meg? Would it be > difficult to change Minix to use this much space? Since it > isn't Messy-Dos, could it address 1 meg without those funny > little LIM boards? > Since most of the address space above 640K is preallocated to hard- and firm-ware, yes it would be difficult to get MINIX to use this space, however the ideas of minix, swapping, and multiple data segments do go together well, since MINIX could just be designed to use the LIM memory as the swap space and only swap in the current process' data memory. > Jason Coughlin Dave Chizmadia @ DOCKMASTER.ARPA
mckee@hpfcdc.HP.COM (Bret McKee) (02/17/89)
>Without even mentioning the effort required to write a more complicated >80x86 C compiler which can support near and far data types, all of Minix >runs on the implicit assumption all message data is in the data segment. I >don't like it, but that's the way it is. ... >Does anyone have a copy of PC-Minix which uses 32bit pointers within the >operating system? I looked at it and felt it would cause distributed >changes to the whole system -- I never got around to it. Once upon a time I had visions of large memory model minix and made all the chages to the kernel so that all message pointers were 32 bit virtual addresses. After I got that working I ran out of free time and haven't gotten back to it since. I was developing under MSC, so the compiler understood far pointers. The changes were not overwelming, but it was not trivial either. Since I have never done the 1.3 update (no free time, remember) I doubt that diffs to my changes would help much. If anyone wants to try it under 1.3, I would be willing to offer and advice I can remember, but since it was about a year ago, my brain is probably pretty empty... >marty --- Bret Mckee Hewlett Packard HP-UX Kernel Group Phone:(303)229-6116 email: mckee@hpfcls or mckee%hpfcde@hplabs.hp.com Of course, these are my opinions...
paula@bcsaic.UUCP (Paul Allen) (02/17/89)
In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >In article <2485@sun.soe.clarkson.edu>, jk0@sun.soe!clutx.clarkson.edu (Jason Coughlin,221 Rey,,) writes: >> [a question about how hard it would be to convert Minix to large-model on PC's] > >Ok, for the non engineers, heres the low down. > >1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB. > There simply is no such machine operation. Microsoft added the ability > to there C compiler output by adding 'far' pointers that basically pull > 2 16 bit addresses from memory (segment:offset) and access one byte/word > with the effective address. Slow, Clumsey, but the only way to do it. Sorry, this is misinformation. The 808{6,8} intrinsically have the ability to address any byte in a 1Mb address space. All memory addresses are formed by shifting a 16-bit segment number left 4 bytes and then adding a 16-bit offset. Typically, the segment is implicitly one of the four hardware segment registers. It is possible, however, to specify both the segment and offset explicitly in an address. This is what is called a 'far' pointer. As you say, far pointers are somewhat slower than near pointers (which are simple 16-bit offsets from an implied segment). Clumsy? You got that right! >2. the .exe format allows for text, data, or both to exceed 64K, by finishing > the relocation to physical address when the program is loaded. This is > the same idea as the ATARI ST uses when it loads. The .exe format allows for text, data, or both to be split between multiple segments, none of which can exceed 64K. The Atari's 68000 processor is not burdened with segments. >[stuff about expanded and extended memory] >The bottom line is that: >A. only the base 640K is readily useable. But it is available. >B. A program can exceed 64 K only by using the Microsoft extensions. > A MINIX would need to create Microsoft C 5.1 to have a CC command. Part of the problem is finding a compiler that knows about far pointers. Microsoft didn't invent far pointers! Apparently, a large-model ACK compiler for the 8086 exists, but for some reason will not fit in Minix. Too bad. Minix is rapidly evolving into a 'real' operating system, and it could use a large-model compiler. Of course, PC Minix is riddled with code that assumes small-model processes, so more than just the compiler is involved. >C. Beyound that, the port from the Atari ST base should be straight forward. > >Maybe someone with a PC and ATARI ST will buy both MINIX versions and do >the port before Easter as Penance. Good Luck. It would be ironic if the final version of PC Minix ends up being a port of the Atari version! Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!pallen
pshen@mit-atrp.UUCP (Paul Shen) (02/17/89)
In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >In article <2485@sun.soe.clarkson.edu>, jk0@sun.soe!clutx.clarkson.edu (Jason Coughlin,221 Rey,,) writes: >> I'm no engineer, but can't the PC address 1 meg? Would it be > >Ok, for the non engineers, heres the low down. > >1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB. > There simply is no such machine operation. Microsoft added the ability > to there C compiler output by adding 'far' pointers that basically pull > 2 16 bit addresses from memory (segment:offset) and access one byte/word > with the effective address. Slow, Clumsey, but the only way to do it. > This is not an invention of Microsoft. The memory address of 80X86 chip is pointed by a pair of CPU registers, namely segment register and offset register. It is true that it takes some clock cycles to change the segment address, but the whole operation can be finished within three instructions, it is not clumsey. If you are familiar with assembly language, the operation is very simple. By the way, the minimum addressable memory of 8086 is 640KB, not 64KB. 80286 is much larger, due to the wider physical address bus. +---------------------------------------------------------------------------+ | Email: pshen@atrp.media.mit.edu | | | Telephone: (617) 253-0370 | Paul Shen | | Address: MIT, E15-384C, Cambridge, Ma 02139 | | +---------------------------------------------------------------------------+
ast@cs.vu.nl (Andy Tanenbaum) (02/17/89)
In article <8752@louie.udel.EDU> ONM64%DMSWWU1A.BITNET@cunyvm.cuny.edu (Kai Henningsen) writes: > > I really am unable to see why >Minix/PC can't support large Applications in the same way that >Minix/ST does. The problem is the brain-damaged 8088/80286 CPU. You can only access 64K segments without doing terrible things, like making all pointers 32 bits. This is slow, bulky, and generally unpleasant. The whole MM has been designed to work with a single linear address space. The 68000 has this. The PC only has it if you restrict yourself to 64K I & D space. Going to a segmented model requires a major change to MM, which I don't want to do. Someday, when the normal low-end PC has a 386 in it, I can envision changing MINIX to use 1 32-bit segment. Andy Tanenbaum (ast@cs.vu.nl)
wbeebe@bilver.UUCP (bill beebe) (02/18/89)
In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB. > There simply is no such machine operation. Microsoft added the ability > to there C compiler output by adding 'far' pointers that basically pull > 2 16 bit addresses from memory (segment:offset) and access one byte/word > with the effective address. Slow, Clumsey, but the only way to do it. The "problem" with the 80x86 family is a little more subtle than that. The so-called 64K limit has to do with the segment limit size. When you say the 80x86 family "totaly lacks the ablity to address beyond 64KB", you neglect to mention that the 64K window can be placed on any 16 byte boundary (called a page) within the 1 meg real address space. It is a very simple matter to re-load a segment register and point anywhere. Furthermore, there is an automatic way for code greater than 64K to execute without explicite segment manipulation. Using far calls allows code in one seperate 64K code segment to execute code in another. You can use the other segments, the DS (data segment), ES (extra segment), and SS (stack segment) to address three seperate 64K data segments for a total of 192K of data. In fact, it's nice to have the stack segment totally seperate from the current code and other data segments to avoid corruption due to stack overflow or underflow. As far as far pointers are concerned, it was Intel who provided the example in their original development tools, PL/M and ASM. Far pointers are slow and clumsy only if data is scattered all over the place. If data are reasonably grouped, but in different areas > 64K apart, then the base segment of one area can be loaded into DS with the other in ES. You then use segment overides to move data between the two areas. One more thing; the 80286 addresses 16 meg in protected mode, with the same 64K segment limit. It's different, but not ugly. >3. Extened (or is it expanded) memory uses a window in the address space of > the machine to access more memory. This is the only scheme on the > 8088/8086. While useful for data bases, and other dedicated programs it > a real mess for loading programs into. Extended memory is memory above 1 meg, available only to 80286 and 80386 based machines. Expanded memory is memory banked into an unused segment in a real address space. That segment is usually $D000:0000. You're correct that it is the only scheme on the 8088/86. However, you can have data and executable code in LIM data space. This is supported in LIM 4.0 drivers and hardware. Furthermore, if you reduce the base memory from 640K to 256K, LIM 4.0 can support swapping LIM memory from the 256K on up. In other words, operating systems that know about LIM can swap multiple 64K pages from the 256K address limit to the 640K limit into and out of the expanded memory pool. Examples of programs that can now do this is DoubleDos 5.0 and Windows v2.1. Limited multitasking is possible with this method. > when running in protected mode. This paging mode was invented by someone > who hated programmers. Its use in MINIX will take much patience! Protected mode was not invented by sadistic design engineers bent on enslaving honest hardworking programmers in segmentation hell. Your comment is indicative of a lack of personal experience and is to be expected from someone mouthing the opinions of others. >Howard C. Johnson >ATT Bell Labs >att!lzaz!hcj >hcj@lzaz.att.com I can't belive this really originated from Bell Labs. *sigh*
lth@uoregon.uoregon.edu (Lars Thomas Hansen) (02/18/89)
In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >In article <2485@sun.soe.clarkson.edu>, jk0@sun.soe!clutx.clarkson.edu (Jason Coughlin,221 Rey,,) writes: >> I'm no engineer, but can't the PC address 1 meg? Would it be >> difficult to change Minix to use this much space? Since it isn't Messy-Dos, >> could it address 1 meg without those funny little LIM boards? > >Ok, for the non engineers, heres the low down. > >1. the 8088,8086,80186,80286 totally lack the ability to address beyond 64KB. > There simply is no such machine operation. Microsoft added the ability > to there C compiler output by adding 'far' pointers that basically pull > 2 16 bit addresses from memory (segment:offset) and access one byte/word > with the effective address. Slow, Clumsey, but the only way to do it. > [...] >The bottom line is that: >B. A program can exceed 64 K only by using the Microsoft extensions. > A MINIX would need to create Microsoft C 5.1 to have a CC command. Firstly: The 640K limit is real under MINIX, too --- it's not MS-DOS that's at fault, but the PC architecture that uses everything above 640K for its own purposes. Live with it. Learn to love it. Secondly: I believe that Mr. Johnson's claims are somewhat inaccurate: The 8086 (and of course the 8088) have built-in support for large (potentially up to 1M) code and data spaces via far jumps/calls/returns and the lds/les instructions. I don't think it is correct to claim that Microsoft has a monopoly here, evidenced by the large number of MS-DOS C compilers that support these larger code/data spaces... So, to assert this completely: the 8086/186 family can indeed address beyond 64K; perhaps not with infinite grace, but they manage. What *is* true, though, is that in order for anything larger than 64K to run under MINIX, the compiler would indeed have to be rewritten to generate far pointers to code and/or data; this would slow down the code a bit and enlarge the size of both code and data. In addition, the MINIX loader and the object file format would probably have to change, since segment addresses would have to be patched into the loaded image *at load time*, another (potentially quite a bit) slowing factor... In my humble (very much so) opinion, it is best to leave PC-MINIX alone (with its 64K limitation) and rather worry about resolving this problem to everybody's benefit when MINIX is ported to a 80386 and can run in protected mode with a 4 Gb limit. --lars
wbeebe@bilver.UUCP (bill beebe) (02/19/89)
In article <2047@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >The problem is the brain-damaged 8088/80286 CPU. You can only access >64K segments without doing terrible things, like making all pointers 32 bits. >This is slow, bulky, and generally unpleasant. The whole MM has been designed >to work with a single linear address space. The 68000 has this. The PC >only has it if you restrict yourself to 64K I & D space. Going to a segmented >model requires a major change to MM, which I don't want to do. Someday, >when the normal low-end PC has a 386 in it, I can envision changing MINIX >to use 1 32-bit segment. Oh, *please* don't call the 8088/80286 brain-damaged! :-). It's been very, very good to me. Your 80386 low-end PC is closer than you think. Intel has dropped the 80386SX price to $89 in single quantities, and $50 in quantity 1000. This makes it directly competitive to the 16 MHz 80286. For your information I have decided to *investigate* porting Minix to the 80376 (no real mode, no paging). The 80376 comes up in protected mode, and I want a rom-based 32-bit version with real-time extensions. *If* I decide to tackle this (I have a hardware design in Schema II+ ), I'll email you with the ugly details. I'll be using Intel's C386 and ASM386 with the builder-binder (I have to anyway).
pshen@mit-atrp.UUCP (Paul Shen) (02/20/89)
In article <419@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes: >..... >For your information I have decided to *investigate* porting Minix >to the 80376 (no real mode, no paging). The 80376 comes up in protected ^ ^ I guess that is just a typo. They should be 80386. Am I right? +---------------------------------------------------------------------------+ | Email: pshen@atrp.media.mit.edu | | | Telephone: (617) 253-0370 | Paul Shen | | Address: MIT, E15-384C, Cambridge, Ma 02139 | | +---------------------------------------------------------------------------+
ceriel@cs.vu.nl (Ceriel Jacobs) (02/20/89)
In article <10171@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: > >Part of the problem is finding a compiler that knows about far pointers. >Microsoft didn't invent far pointers! Apparently, a large-model ACK compiler >for the 8086 exists, but for some reason will not fit in Minix. Too bad. This is not true. There is no large-model ACK compiler for the 8086. -- Ceriel Jacobs, Dept. of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands Voice: +31 20 5485577 Email: ceriel@cs.vu.nl
chasm@killer.DALLAS.TX.US (Charles Marslett) (02/20/89)
In article <3576@mit-amt>, pshen@mit-atrp.UUCP (Paul Shen) writes: > In article <419@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes: > >..... > >For your information I have decided to *investigate* porting Minix > >to the 80376 (no real mode, no paging). The 80376 comes up in protected > ^ ^ > I guess that is just a typo. They should be 80386. Am I right? Nope, the 80376 (note, 10 LESS than 80386) is a 386 minus paging hardware, and minus real mode -- crippled so as not to be usable as a PC clone processor and probably noticably simpler inside. It is, I think, Intel's trial balloon to see if they can break from the 8088 tradition. . . If they had only left out segments rather than paging, I'd have been pleased as punch. Charles Marslett chasm@killer.dallas.tx.us
wbeebe@rtmvax.UUCP (Bill Beebe) (02/21/89)
In article <3576@mit-amt> pshen@atrp.media.mit.edu (Paul Shen) writes: >>to the 80376 (no real mode, no paging). The 80376 comes up in protected > ^ ^ > I guess that is just a typo. They should be 80386. Am I right? Sorry. That is *NOT* a typo. In April 1988, when Intel announced the 80960 (Officially :-), they also announced the 80376. The 80376 was a stripped down 80386 with a 32-bit internal architecture, 16-bit data and 24-bit address bus. It could not support real mode, and it did not have the paging unit. It did support the full segmentation and protection architecture of the 80386 and the 80386's instruction set. It runs at 16 MHz. What makes the 80376 interesting is that it was aimed at the embedded market. It was designed to be a cheap '386 for folks who didn't want all the other stuff in the '386 that made it so expensive. So the 80376, a "de-DOSed" 80386, was introduced for $99. Now Intel has dropped the price on the 80386SX to $89, with even greater price breaks in quantity. The question now becomes will the 80376 get even cheaper, and if not, then what's the reason for buying the 80376 over the 80386SX? Of course, I got mine as samples :-). And it makes good sense to go ahead and use the 80376 as a PM development platform, because code written on the 80376 is easily ported to the "real" 80386 family :-). Sorry for the confusion.
vo@micomvax.UUCP (Vladimir Orlt) (02/23/89)
In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB -the 8088,8086,80186 address 1Mbyte -the 80286 addresses 1Mbyte in 'real' mode, 16Mbyte in 'protected' mode -the 80386 addresses 1Mbyte(plus 64K) in 'real' mode, 4 Gigabytes in 'protected'mode, 16Mbyte(plus 64K) in '286-protected mode' all of the above addressing is performed by combining segment and offset registers; only the offset is restricted to 64K. Any machine cycle to memory performs the segment+offset combination to generate a physical address on the CPU's address lines; in 'real' mode, the combination is straightforward; in 'protected' mode, it can be complicated. The ability to modify segment registers is obviously an integral part of the CPUs' instruction set; compilers use it, but you can write assembly code (or machine code) to do it as well. >3. Extened (or is it expanded) memory uses a window in the address space of > the machine to access more memory. This is the only scheme on the > 8088/8086. 'Expanded' memory is the correct term. Such scientists, those PC people... >4. the 80286 supports expanded(or is is extended) memory that addressable > when running in protected mode. This paging mode... 'Extended' memory is the correct term. In the 80286, this is not a paging mode but a fancy segmentation mode. Only the 80386 supports true paging, in addition to 80286 features. Vlad the re-mailer ...philabs!micomvax!vo "IBM is a concept by which we measure our pain" (apologies to J.Lennon)
allbery@ncoast.ORG (Brandon S. Allbery) (02/24/89)
As quoted from <3570@mit-amt> by pshen@mit-atrp.UUCP (Paul Shen): +--------------- | By the way, the minimum addressable memory of 8086 is 640KB, | not 64KB. 80286 is much larger, due to the wider physical address bus. +--------------- Sigh. The 8086/8088 can address 1MB of memory. The reason why DOS (and Minix) are limited to 640K is because the addresses from 640K up are used by other things: at 640K is EGA/VGA screen RAM, at 720K is MDA/Hercules RAM, at 768K is CGA RAM, and the rest is ROM (EGA BIOS, if any, HD, and BIOS). This is the design of the IBM PC, *not* of the 8088. The 80286 can address more memory than this not only because of the address bus but also because of a bit of segment subterfuge referred to as "protected mode", whereby a "segment address" is actually a tag value used to find the *real* address in a table. It still has 64K segments, however. (The table referred to above also includes MMU information, such as read/write permissions; hence the name "protected mode".) The 80386 not only has an even larger address bus, it has larger segment registers. Which means larger segments -- 4GB instead of 64K. I have yet to hear of a medium-model 386 program, much less large or huge model.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser