* [TUHS] Redoing "V6on286" or porting V7...? @ 2005-11-14 21:34 Norman Wilson 2005-11-14 22:59 ` Brantley Coile 0 siblings, 1 reply; 18+ messages in thread From: Norman Wilson @ 2005-11-14 21:34 UTC (permalink / raw) Brantley Coile: i don't know that it's a squese. a version of v6 ran on an lsi-11 with very little ram. ======= If you're thinking of Mini-UNIX, it's a bit of a stretch to call it `V6 running on an LSI-11.' I think the original LSI-11 had no memory management; in any case, Mini-UNIX didn't use it, but was a throwback to the early days of the PDP-7 and the 11/20 (neither of which had memory management). Only one process could be in memory at a time; to let another process run meant swapping the first completely out of memory. I believe there's a paper in the 1978 all-UNIX issue of the Bell Systems Technical Journal about Mini-UNIX or its immediate predecessor. As I recall, there were additional compromises; e.g. the shell quietly translated a | b to a >tempfile; b <tempfile; rm tempfile because that was much faster than the thrashing that often resulted from trying to let a and b run concurrently. Mini-UNIX might be a simpler starting point to get a system running on a 286. Just don't think of it as full V6; it's not. Norman Wilson Toronto ON ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-14 21:34 [TUHS] Redoing "V6on286" or porting V7...? Norman Wilson @ 2005-11-14 22:59 ` Brantley Coile 0 siblings, 0 replies; 18+ messages in thread From: Brantley Coile @ 2005-11-14 22:59 UTC (permalink / raw) you're right. i was thinking of mini-Unix. my point was just that you can do a lot with very little. > Brantley Coile: > > i don't know that it's a squese. a version of v6 ran on an lsi-11 > with very little ram. > > ======= > > If you're thinking of Mini-UNIX, it's a bit of a stretch to call > it `V6 running on an LSI-11.' I think the original LSI-11 had no > memory management; in any case, Mini-UNIX didn't use it, but was > a throwback to the early days of the PDP-7 and the 11/20 (neither > of which had memory management). Only one process could be in > memory at a time; to let another process run meant swapping the > first completely out of memory. > > I believe there's a paper in the 1978 all-UNIX issue of the Bell > Systems Technical Journal about Mini-UNIX or its immediate > predecessor. As I recall, there were additional compromises; > e.g. the shell quietly translated > a | b > to > a >tempfile; b <tempfile; rm tempfile > because that was much faster than the thrashing that often > resulted from trying to let a and b run concurrently. > > Mini-UNIX might be a simpler starting point to get a system > running on a 286. Just don't think of it as full V6; it's not. > > Norman Wilson > Toronto ON > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? @ 2005-11-09 17:26 Lyrical Nanoha 2005-11-09 21:54 ` M. Warner Losh 2005-11-09 22:03 ` Brantley Coile 0 siblings, 2 replies; 18+ messages in thread From: Lyrical Nanoha @ 2005-11-09 17:26 UTC (permalink / raw) I've thought, since there doesn't seem to be a working "V6on286", maybe I should try porting it myself though I'm not very familiar with the Ancient Unix sources or with the ancient C used. The oldest compiler I've got that will compile is Turbo C++ 1.01 from 1990 and it's an ANSI C compiler. (I do think it'll compile late K&R, but there's weirdnesses in the C used by V6.) Having an emulator like QEMU handy is a nice plus. I could prolly build everything onto a 1.44 MB disk image and boot it in emulation. I'm thinking I'd want to create tools for transferring files into and out of disk images, and a bootloader to put on the first sector of the disk (though, 512 bytes is awful small...) Any ideas? -uso. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-09 17:26 Lyrical Nanoha @ 2005-11-09 21:54 ` M. Warner Losh 2005-11-09 22:03 ` Brantley Coile 1 sibling, 0 replies; 18+ messages in thread From: M. Warner Losh @ 2005-11-09 21:54 UTC (permalink / raw) : disk images, and a bootloader to put on the first sector of the disk : (though, 512 bytes is awful small...) It is a very useful excersize to concentrate on the small. 512 bytes is plenty to play with... Although many boot loaders are boring and just load the next boot stage or two and jump to that. Warner ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-09 17:26 Lyrical Nanoha 2005-11-09 21:54 ` M. Warner Losh @ 2005-11-09 22:03 ` Brantley Coile 2005-11-12 6:13 ` Albert Cahalan 1 sibling, 1 reply; 18+ messages in thread From: Brantley Coile @ 2005-11-09 22:03 UTC (permalink / raw) my suggestions are as follows (i assume you really mean 8086 mode): use a pdp emulator to run a donor system and do the port from there. using a floppy to boot is a great idea. i've written several boot straps to boot from the floppy that configure the serial port, and put the processor in 32-bit mode. it's tight, but not too hard. you have a great advantage in that you're going to stick to 16 bit so you can use the bios. 512 bytes in that case is tons of space. first job is to get an assembler and compiler for the 8086. i would use the mit's compilers/assembler from the 1980's. if you can't find a copy, i have one. next, figure out how you are going to manage memory. avoiding protected memory would make things much easier. just have each process use a full 64K of memory for the data segment. for text you don't have to worry about stepping on anything, so they don't have to be a full 64k. that'll give you 10 processes worth of processes. you can just swap if you want any more. the routines you'll need to fix are in /usr/sys/ken/main.c. then you need to rewrite the trap code to use the pc's interrupts. this is very straight forward. you'll have to write some small assembler code to setup the stack frames to get into trap.c. next you'll need to write device drivers for the screen/keyboard, the clock, and the floppy. later you can write an ATA driver and get a mbr and hard disk boot strap. if you want to do a 32-bit version, then things are a little different. but this should give you the v6 in about as little work as can be. Brantley Coile -------------- next part -------------- An embedded message was scrubbed... From: Lyrical Nanoha <LyricalNanoha@dosius.net> Subject: [TUHS] Redoing "V6on286" or porting V7...? Date: Wed, 9 Nov 2005 12:26:32 -0500 (EST) Size: 2709 URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20051109/86c19884/attachment.mht> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-09 22:03 ` Brantley Coile @ 2005-11-12 6:13 ` Albert Cahalan 2005-11-12 13:18 ` Brantley Coile 0 siblings, 1 reply; 18+ messages in thread From: Albert Cahalan @ 2005-11-12 6:13 UTC (permalink / raw) On 11/9/05, Brantley Coile <brantley at coraid.com> wrote: > my suggestions are as follows (i assume you really mean 8086 mode): That wouldn't be a good match. I believe you want this: * 16-bit * protected mode * no paging * 8 or 16 segments * 128 kB of the memory * no FPU > using a floppy to boot is a great idea. i've written several boot > straps to boot from the floppy that configure the serial port, and put > the processor in 32-bit mode. it's tight, but not too hard. you have > a great advantage in that you're going to stick to 16 bit so you can > use the bios. 512 bytes in that case is tons of space. 512 is easy until you try to handle more than one machine. :-( > next you'll need to write device drivers for the screen/keyboard, the > clock, and the floppy. later you can write an ATA driver and get a > mbr and hard disk boot strap. I think you need a 4 MB disk and a 10 MB disk. :-) > if you want to do a 32-bit version, then things are a little > different. but this should give you the v6 in about as little > work as can be. You might use a 32-bit CPU in 16-bit mode. Then you could use a 32-bit limit on the FS or GS segment for easier physical memory access from the kernel. (use an opcode prefix as needed) ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-12 6:13 ` Albert Cahalan @ 2005-11-12 13:18 ` Brantley Coile 2005-11-13 20:16 ` Peter Jeremy 0 siblings, 1 reply; 18+ messages in thread From: Brantley Coile @ 2005-11-12 13:18 UTC (permalink / raw) > I believe you want this: > > * 16-bit > * protected mode > * no paging > * 8 or 16 segments > * 128 kB of the memory > * no FPU i may be wrong, but i don't think you want the segments. pdp-11 segments divided the address space into eight, well, segments. each could be grow up or grow down and had a physical base and a limit. intel segments don't work that way. the major difference is that the segment selector, instead of being the upper most three bits of the virtual address, is not even in the address space at all. so the eight, for a pdp-11/40 say, or the sixteen for the 11/70 don't really apply. instead just give each data segment the whole 64k address space and it'll not klobber anybody else. just itself. there's not really any reason not to use the whole 640K. > >> using a floppy to boot is a great idea. i've written several boot >> straps to boot from the floppy that configure the serial port, and put >> the processor in 32-bit mode. it's tight, but not too hard. you have >> a great advantage in that you're going to stick to 16 bit so you can >> use the bios. 512 bytes in that case is tons of space. > > 512 is easy until you try to handle more than one machine. :-( didn't quit understand this. the boot sector is a short driver for the media you're booting. the floopy or the harddisk. it has to know about the file system enough to pull out /boot. it can use the drivers in the bios. > >> next you'll need to write device drivers for the screen/keyboard, the >> clock, and the floppy. later you can write an ATA driver and get a >> mbr and hard disk boot strap. > > I think you need a 4 MB disk and a 10 MB disk. :-) you're correct to imply that v6 takes up MUCH less space than other systems. it's amazing how small you can run this. the root in the 6th edition system is only 1.4MB. and that includes the normal binaries, libraries and the source to the kernel. it'll run great on a floopy. > >> if you want to do a 32-bit version, then things are a little >> different. but this should give you the v6 in about as little >> work as can be. > > You might use a 32-bit CPU in 16-bit mode. Then you could use > a 32-bit limit on the FS or GS segment for easier physical memory > access from the kernel. (use an opcode prefix as needed) you could. i still think that just plain old native mode would be a great way to run 6th Ed. bc 1011 1100 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-12 13:18 ` Brantley Coile @ 2005-11-13 20:16 ` Peter Jeremy 2005-11-14 9:38 ` Wesley Parish ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: Peter Jeremy @ 2005-11-13 20:16 UTC (permalink / raw) I've also looked at this in the past. I lost interest when my intended target box died (and I realised I didn't have the free time). On 2005-Nov-12 08:18:50 -0500, Brantley Coile <brantley at coraid.com> wrote: >i may be wrong, but i don't think you want the segments. pdp-11 >segments divided the address space into eight, well, segments. each >could be grow up or grow down and had a physical base and a limit. >intel segments don't work that way. the major difference is that the >segment selector, instead of being the upper most three bits of the >virtual address, is not even in the address space at all. Actually the 286 MMU is very primitive compared to the PDP-11. One crucial difference is that Unix has the implicit assumption that the stack is in the data space - which is not true on the 286. This difference is fairly critical to Unix and makes it impossible to accurately reproduce the traditional Unix memory protection. >so the eight, for a pdp-11/40 say, or the sixteen for the 11/70 don't >really apply. instead just give each data segment the whole 64k >address space and it'll not klobber anybody else. just itself. This is fairly wasteful of RAM. Keep in mind that V6 cannot page - a process is either entirely in memory or entirely on disk. If you limit yourself to 640K RAM, you are probably restricting yourself to about 6 resident processes. And swapping means moving 64K of data to/from disk. This approach also makes brk(2) a no-op. There's nothing to prevent a process using as much heap as it wants (or crashing into the stack). (No SIGSEGV or SIGBUS errors). >you're correct to imply that v6 takes up MUCH less space than other >systems. it's amazing how small you can run this. the root in the >6th edition system is only 1.4MB. and that includes the normal >binaries, libraries and the source to the kernel. it'll run great on >a floopy. You will need to have a swap partition. And if each process has a 64K data segment, you'll need a comparatively large amount of swap. The biggest disadvantage of a floppy will be performance - latency of about 80msec, I/O of about 40KB/sec. Have you identified a suitable C compiler? There aren't many open source 16-bit x86 compilers, especially ones that can run in 16-bit mode. None of the ones I found generated particularly good code. This may impact you ability to get the larger utilities (and maybe the kernel) to fit into 64K I-space. -- Peter Jeremy This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-13 20:16 ` Peter Jeremy @ 2005-11-14 9:38 ` Wesley Parish 2005-11-14 15:45 ` Brantley Coile ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Wesley Parish @ 2005-11-14 9:38 UTC (permalink / raw) On Mon, 14 Nov 2005 09:16, Peter Jeremy wrote: > I've also looked at this in the past. I lost interest when my > intended target box died (and I realised I didn't have the free time). > > On 2005-Nov-12 08:18:50 -0500, Brantley Coile <brantley at coraid.com> wrote: > >i may be wrong, but i don't think you want the segments. pdp-11 > >segments divided the address space into eight, well, segments. each > >could be grow up or grow down and had a physical base and a limit. > >intel segments don't work that way. the major difference is that the > >segment selector, instead of being the upper most three bits of the > >virtual address, is not even in the address space at all. > > Actually the 286 MMU is very primitive compared to the PDP-11. One > crucial difference is that Unix has the implicit assumption that the > stack is in the data space - which is not true on the 286. This > difference is fairly critical to Unix and makes it impossible to > accurately reproduce the traditional Unix memory protection. > > >so the eight, for a pdp-11/40 say, or the sixteen for the 11/70 don't > >really apply. instead just give each data segment the whole 64k > >address space and it'll not klobber anybody else. just itself. > > This is fairly wasteful of RAM. Keep in mind that V6 cannot page - > a process is either entirely in memory or entirely on disk. If you > limit yourself to 640K RAM, you are probably restricting yourself > to about 6 resident processes. And swapping means moving 64K of > data to/from disk. > > This approach also makes brk(2) a no-op. There's nothing to prevent a > process using as much heap as it wants (or crashing into the stack). > (No SIGSEGV or SIGBUS errors). > > >you're correct to imply that v6 takes up MUCH less space than other > >systems. it's amazing how small you can run this. the root in the > >6th edition system is only 1.4MB. and that includes the normal > >binaries, libraries and the source to the kernel. it'll run great on > >a floopy. > > You will need to have a swap partition. And if each process has a > 64K data segment, you'll need a comparatively large amount of swap. > The biggest disadvantage of a floppy will be performance - latency > of about 80msec, I/O of about 40KB/sec. > > Have you identified a suitable C compiler? There aren't many open > source 16-bit x86 compilers, especially ones that can run in 16-bit > mode. None of the ones I found generated particularly good code. > This may impact you ability to get the larger utilities (and maybe > the kernel) to fit into 64K I-space. Would it be possible to use some of the DOS ones? At least to bootstrap a more true-to-Unix one? I'm thinking of the likes of bcc, available plus source at the FreeDOS web archive. Or OpenWatcom's DOS 16-bit. Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-13 20:16 ` Peter Jeremy 2005-11-14 9:38 ` Wesley Parish @ 2005-11-14 15:45 ` Brantley Coile [not found] ` <8a61b612cf43394f33e6531339fe4263@coraid.com> 2005-11-15 3:08 ` Greg Haerr 3 siblings, 0 replies; 18+ messages in thread From: Brantley Coile @ 2005-11-14 15:45 UTC (permalink / raw) this is a nice conversation. you're observations are all correct. see my additional comments below. > Actually the 286 MMU is very primitive compared to the PDP-11. One > crucial difference is that Unix has the implicit assumption that the > stack is in the data space - which is not true on the 286. This > difference is fairly critical to Unix and makes it impossible to > accurately reproduce the traditional Unix memory protection. absolutely correct. in fact, i've never really figured out what intel was thinking with the stack segment in protect mode. you can't use it in C, you can't even use it in a Pascal like language, or any other language that uses call-by-reference procedure parameters. > >>so the eight, for a pdp-11/40 say, or the sixteen for the 11/70 don't >>really apply. instead just give each data segment the whole 64k >>address space and it'll not klobber anybody else. just itself. > > This is fairly wasteful of RAM. Keep in mind that V6 cannot page - > a process is either entirely in memory or entirely on disk. If you > limit yourself to 640K RAM, you are probably restricting yourself > to about 6 resident processes. And swapping means moving 64K of > data to/from disk. true, but your numbers are a bit off. 640k / 64k = 10 not 6. the kernel will take only 2, so you should have 8. the shared segment for the shell is about 32k, so maybe you're not that far of. if the objective is to have a system that is real and has the feel of what it was like to use a 6th Edition Unix system, this isn't a big deal. you and edit, compile and run programs on it. > > This approach also makes brk(2) a no-op. There's nothing to prevent a > process using as much heap as it wants (or crashing into the stack). > (No SIGSEGV or SIGBUS errors). ture enough. but that's the case if you use the 286 segmens as well. either that or you make the data==stack segment a little short, then set the stack to a fixed size near the bottom of the data segment. if you run off the end or grow the stack too deep, you wrap around and hit the limit of the segment. > >>you're correct to imply that v6 takes up MUCH less space than other >>systems. it's amazing how small you can run this. the root in the >>6th edition system is only 1.4MB. and that includes the normal >>binaries, libraries and the source to the kernel. it'll run great on >>a floopy. > > You will need to have a swap partition. And if each process has a > 64K data segment, you'll need a comparatively large amount of swap. > The biggest disadvantage of a floppy will be performance - latency > of about 80msec, I/O of about 40KB/sec. i wouldn't bother with a swap device on the floopy version. you'd just just use this version to get the disk driver working so you could have real swap. swaping to modern disks is pretty fast. i can swap an entire 64k segment in less than a millisecond, so it would seem much faster than the original. > > Have you identified a suitable C compiler? There aren't many open > source 16-bit x86 compilers, especially ones that can run in 16-bit > mode. None of the ones I found generated particularly good code. > This may impact you ability to get the larger utilities (and maybe > the kernel) to fit into 64K I-space. the mit x86 stuff would be where i'd start. i haven't looked to see if you need to tweak the assignment operators to avoid having to s/=+/+=/, but it might already be done. it's all 16 bit stuff: port of PCC, assembler and loader. an enjoyable discussion. wish i had time to work on it. bc ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <8a61b612cf43394f33e6531339fe4263@coraid.com>]
* [TUHS] Redoing "V6on286" or porting V7...? [not found] ` <8a61b612cf43394f33e6531339fe4263@coraid.com> @ 2005-11-14 19:49 ` Peter Jeremy 2005-11-14 20:31 ` Brantley Coile 2005-11-16 21:41 ` Lyrical Nanoha 0 siblings, 2 replies; 18+ messages in thread From: Peter Jeremy @ 2005-11-14 19:49 UTC (permalink / raw) On 2005-Nov-14 10:45:13 -0500, Brantley Coile <brantley at coraid.com> wrote: >> This is fairly wasteful of RAM. Keep in mind that V6 cannot page - >> a process is either entirely in memory or entirely on disk. If you >> limit yourself to 640K RAM, you are probably restricting yourself >> to about 6 resident processes. And swapping means moving 64K of >> data to/from disk. > >true, but your numbers are a bit off. 640k / 64k = 10 not 6. I realise that. > the kernel will take only 2, so you should have 8. I was assuming split I+D, with the data segment fixed at 64K. This means that you have (64K + code) per process. If you have code plus data in 64K then you can fit more, but I think that was getting to be a squeeze even on V6. (And would definitely write off something like 2BSD). >the mit x86 stuff would be where i'd start. i haven't looked to see >if you need to tweak the assignment operators to avoid having >to s/=+/+=/, but it might already be done. Given an open-source compiler, it would be fairly easy to retrofit the =+ operators into the lexer. (Probably easier than cleaning up the code). The alternative is to start with something later (eg 2BSD) but code quality then becomes far more of an issue (because 2BSD tends to push the I-space limits in lots of areas). >it's all 16 bit stuff: port of PCC, assembler and loader. The x86 instruction set and registers are nothing like as regular and orthogonal as the PDP-11. In particular, there are _no_ general purpose registers - every register has has a particular purpose and either you need to do data-flow analysis to work out what register to load something into, or you (basically) give up and load from memory as needed. You could port PCC but this would be much more difficult than (say) a M68K port. You'd probably need a fairly decent peep-hole optimiser to get good results. Wesley Parish mentioned bcc and OpenWatcom. I looked into the former and it's probably the best starting point (though, with due respect to BDE, the code it generates could be better). Assuming that Unix fits into the C subset implemented by bcc, you'd be better off spending the effort on improving bcc than porting PCC. At the time I looked, OpenWatcom was either still vapourware or not self-hosting. >an enjoyable discussion. wish i had time to work on it. Agreed. -- Peter Jeremy This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-14 19:49 ` Peter Jeremy @ 2005-11-14 20:31 ` Brantley Coile 2005-11-16 21:41 ` Lyrical Nanoha 1 sibling, 0 replies; 18+ messages in thread From: Brantley Coile @ 2005-11-14 20:31 UTC (permalink / raw) > On 2005-Nov-14 10:45:13 -0500, Brantley Coile <brantley at coraid.com> wrote: > I was assuming split I+D, with the data segment fixed at 64K. This > means that you have (64K + code) per process. If you have code plus > data in 64K then you can fit more, but I think that was getting to > be a squeeze even on V6. (And would definitely write off something > like 2BSD). i don't know that it's a squese. a version of v6 ran on an lsi-11 with very little ram. there is only two process required to run in v6, init and the shell. sched doesn't count; it has no user space. > >>the mit x86 stuff would be where i'd start. i haven't looked to see >>if you need to tweak the assignment operators to avoid having >>to s/=+/+=/, but it might already be done. > > Given an open-source compiler, it would be fairly easy to retrofit the > =+ operators into the lexer. (Probably easier than cleaning up the > code). The alternative is to start with something later (eg 2BSD) but > code quality then becomes far more of an issue (because 2BSD tends to > push the I-space limits in lots of areas). very good point. it'll be easier that i thought. > >>it's all 16 bit stuff: port of PCC, assembler and loader. > > The x86 instruction set and registers are nothing like as regular and > orthogonal as the PDP-11. In particular, there are _no_ general > purpose registers - every register has has a particular purpose and > either you need to do data-flow analysis to work out what register to > load something into, or you (basically) give up and load from memory > as needed. You could port PCC but this would be much more difficult > than (say) a M68K port. You'd probably need a fairly decent peep-hole > optimiser to get good results. the mit is already ported. every thing you said about how ugly the x86 is and how nice the pdp-11 was, i agree with. i have lived with both of them and with the 68k. although the 68k's A and D registers are kind of a hacky. but not mater, mit's already done the work. as far as trying to optimize the register use, i think that for modern pentium processors it's not that important. L1 caches are very fast and function about as fast as local registers anyway. this the the good thing about a very bad instruction set with too few registers. the vendor has to invent very clever ways to stay competitive with better systems. in a way the hardware is doing all the optimzation for us. > > Wesley Parish mentioned bcc and OpenWatcom. I looked into the former > and it's probably the best starting point (though, with due respect to > BDE, the code it generates could be better). Assuming that Unix fits > into the C subset implemented by bcc, you'd be better off spending the > effort on improving bcc than porting PCC. At the time I looked, > OpenWatcom was either still vapourware or not self-hosting. again, no port required. the mit x86 stuff has already done that. i have code with the following readme. --- Directory setup: c86, lib86: for 8087-equiped systems. nc86,nlib86: for non-8087 systems. You should install the following files into some directory on your search path (on our system we use /usr/local): cc86 ; shell script implements "cc" but for 8086 a86/a86 ; the assembler a86/ld86 ; the loader a86/cvt86 ; .ld output to .com file (a la IBM DOS) conversion c86/c86 ; the C compiler Regular 4.1BSD programs used: ar ; used for preparing loader libraries /lib/cpp ; C preprocessor The cc86 script expects to find the libc.a and crt files in /projects/compilers/8086/lib86 -- if you don't put them there, you'll have to update cc86... The compiler produces assembly language output suitable for a86. It is a 16-bit compiler; output code does not touch the segment regs, so it is possible to have separate instruction and data segments (see lib86/csu/crt0.a86 for the start up routine we use on our IBM Personal computer to set up the segment regs, etc. from info in the .com file). Currently floating point and long arithmetic is implemented using 8087 instructions. Although the assembler produces ".b" files, they have exactly the same format as ".o" files under 4.1BSD -- things like nm and size will work, and, most importantly, ld. Using ld with the -N, -X and -r options (see cc86 for an example) will produce a file that cvt86 can convert into an IBM DOS format .com file for the IBM Personal Computer. --- looking at the source files, it's definitly PCC. (and it already does the =+ stuff.) you keep tempting me! (get behind me, Satan!) > >>an enjoyable discussion. wish i had time to work on it. > > Agreed. > > -- > Peter Jeremy > > This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. > > This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-14 19:49 ` Peter Jeremy 2005-11-14 20:31 ` Brantley Coile @ 2005-11-16 21:41 ` Lyrical Nanoha [not found] ` <17277.62390.986234.433543@hod.localdomain> 1 sibling, 1 reply; 18+ messages in thread From: Lyrical Nanoha @ 2005-11-16 21:41 UTC (permalink / raw) I'm the original poster of this thread. On Tue, 15 Nov 2005, Peter Jeremy wrote: > Wesley Parish mentioned bcc and OpenWatcom. I looked into the former > and it's probably the best starting point (though, with due respect to > BDE, the code it generates could be better). Assuming that Unix fits > into the C subset implemented by bcc, you'd be better off spending the > effort on improving bcc than porting PCC. At the time I looked, > OpenWatcom was either still vapourware or not self-hosting. I don't think everything needs to be bootstrapped with an open-source compiler. I have Turbo C++ 1.01 which is a more than adequate C compiler for anything I've done with it (ranging from clones of Unix tools to a COMMAND.COM to an Apple //e emulator). Whatever does the job is fine for me. So getting the kernel up and getting files in and out of the image until a native C compiler is ready (pcc?) can be done with anything, practically. QEMU is a good enough testbed, and gives you well-defined hardware. Once everything is up and running, then maybe one can migrate on to newer systems (V7, 2BSD), though V6 should be simple enough as a starting point, provided most of it is in C (I haven't really looked). -uso. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <17277.62390.986234.433543@hod.localdomain>]
* [TUHS] Redoing "V6on286" or porting V7...? [not found] ` <17277.62390.986234.433543@hod.localdomain> @ 2005-11-18 17:59 ` Lyrical Nanoha 2005-11-19 4:17 ` Brantley Coile 0 siblings, 1 reply; 18+ messages in thread From: Lyrical Nanoha @ 2005-11-18 17:59 UTC (permalink / raw) On Fri, 18 Nov 2005, Markus E Leypold wrote: > I wonder, wether you realize that getting pcc "ready" would mean > writing a x86 backend for it. Or does it already have one? From what I heard it does, unless I misremembered... -uso. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-18 17:59 ` Lyrical Nanoha @ 2005-11-19 4:17 ` Brantley Coile 0 siblings, 0 replies; 18+ messages in thread From: Brantley Coile @ 2005-11-19 4:17 UTC (permalink / raw) the mit stuff already has the back end and the assembler/loader. the assembler for the pdp-11 was written by Dennis Ritchie and is a wonder to behold. Brantley Lyrical Nanoha wrote: > On Fri, 18 Nov 2005, Markus E Leypold wrote: > > >>I wonder, wether you realize that getting pcc "ready" would mean >>writing a x86 backend for it. Or does it already have one? > > >From what I heard it does, unless I misremembered... > > -uso. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/t uhs ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-13 20:16 ` Peter Jeremy ` (2 preceding siblings ...) [not found] ` <8a61b612cf43394f33e6531339fe4263@coraid.com> @ 2005-11-15 3:08 ` Greg Haerr 2005-11-15 3:40 ` Peter Jeremy 3 siblings, 1 reply; 18+ messages in thread From: Greg Haerr @ 2005-11-15 3:08 UTC (permalink / raw) > One > crucial difference is that Unix has the implicit assumption that the > stack is in the data space - which is not true on the 286. This > difference is fairly critical to Unix and makes it impossible to > accurately reproduce the traditional Unix memory protection. I don't understand this. If SS is set to DS, in any 16 bit mode, then doesn't this accomplish the accurate reproduction? I realize that a 32-bit mode would be required for limit checking. Regards, Greg ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-15 3:08 ` Greg Haerr @ 2005-11-15 3:40 ` Peter Jeremy 2005-11-15 13:30 ` Brantley Coile 0 siblings, 1 reply; 18+ messages in thread From: Peter Jeremy @ 2005-11-15 3:40 UTC (permalink / raw) On 2005-Nov-14 19:08:52 -0800, Greg Haerr <greg at censoft.com> wrote: >> One >> crucial difference is that Unix has the implicit assumption that the >> stack is in the data space - which is not true on the 286. This >> difference is fairly critical to Unix and makes it impossible to >> accurately reproduce the traditional Unix memory protection. > >I don't understand this. If SS is set to DS, in any 16 bit mode, >then doesn't this accomplish the accurate reproduction? I realize >that a 32-bit mode would be required for limit checking. You can make SS and DS the same but this means that there's nothing stopping the stack growing down into the heap or vice versa. This makes the stack accessible from the data space but gives no protection (note that I was referring to reproducing Unix protection). -- Peter Jeremy This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] Redoing "V6on286" or porting V7...? 2005-11-15 3:40 ` Peter Jeremy @ 2005-11-15 13:30 ` Brantley Coile 0 siblings, 0 replies; 18+ messages in thread From: Brantley Coile @ 2005-11-15 13:30 UTC (permalink / raw) > On 2005-Nov-14 19:08:52 -0800, Greg Haerr <greg at censoft.com> wrote: >>> One >>> crucial difference is that Unix has the implicit assumption that the >>> stack is in the data space - which is not true on the 286. This >>> difference is fairly critical to Unix and makes it impossible to >>> accurately reproduce the traditional Unix memory protection. >> >>I don't understand this. If SS is set to DS, in any 16 bit mode, >>then doesn't this accomplish the accurate reproduction? I realize >>that a 32-bit mode would be required for limit checking. > > You can make SS and DS the same but this means that there's nothing > stopping the stack growing down into the heap or vice versa. This > makes the stack accessible from the data space but gives no protection > (note that I was referring to reproducing Unix protection). sorry this message is so long. i wish it was better written, but at least it's early in the day, and i've had my diet co-cola (as we say here in the south). this mess is why i made the suggestion just to use a full 64k for the data segments. but there is a way to get protection of a sort. Peter's right. setting ss==ds will work but it leaves the data segment unprotected. in protect mode, data segments can be configured to be valid above a limit or below. for stacks you can make them valid above a limit and move the limit down as the stack grows. (by above i mean address with larger values and by down i mean addresses with smaller values.) but one can't easily use this when implementing C. when the processor does a stack operation, a push, pop, call, return and so on, it uses the stack segment. when the processor feteches or stores an operand or a result, it uses the data segment. even if the data segment and stack segments had the same base register, you couldn't use the grow-down feature to protect the data from the stack growing into it. the problem is local varibles and call by reference. local varibles live on the stack, but if you tried to access them with using the data segment selector, you would get a protection violation because you're doing a data fetch above the data limit. since it's a data fetch it's using the data segment. you might think that the compiler could know where the variable is and use an instruction prefix to override the data segment and use the stack segment instead. that would work for the simple case, but what do you do when you take the address of the variable? you loose the information that it's a local variable on the stack and don't know which segment to use when dereferencing the pointer. when the protect mode was designed in intel, Pascal was all the rage in schools of higher learning. C had yet to become the ubiquitous notation. since Pascal didn't allow addresses to be taken of arbitrary varibles, for years i just assumed the intel design was an arifact of designing hardware to run Pascal. (intel indeed includes a feature that is only useful for Algol like languages that have nested procedures. look at the definition of the `enter' instruction.) but i was wrong. Pascal, (and Modula, and Oberon) allow procedure parameters to be either call by value or call by reference. a call by reference parameter is a kind of pointer. there is no way to know if you've been called with a pointer to a global variable, a variable allocated on the heap or a local variable, without including more information than just the address. so, what were they thinking? i've no idea. all other segmented architectures include the segment selector in the high bits of the virtual address, as does the pdp-11, as did Multics. in fact, what intel calls a page directory is called a segment table in many other systems. but of course the word segment was already taken. in the mid 1980's we used intel compilers with different memory models. the small model did much as i'm suggesting. just give'm 64k and have at it. there was also a middle model with 64k data and more than one code segment. large model allowed more than 64k of data, but a single array was limited to 64k. there was also a huge model. as you went from small to huge, the code generated by the compiler would include more and more load segment selector instructions. while this looks bad, it's really quite worse than it looks. when one loads a selector, a 16-bit value, into the segment register it causes the processor to load a 64 bit segment descriptor. and it does this for every varible access in large and huge models. yuck! all that is why i suggest just giving the process 64k and be done with it. it's 6th edition after all. but last night i thought of a couple of reasons to turn on protect mode. first, there is a way to use it to limit the stack growth and stop it from growing into the data. you must decide how large a stack you want to allow. then put the base of your static data just above the stack and have the stack grow down to the bottom of your data segment. you use protect mode to allow 64k-N, so you can't just wrap around the data segment. if the stack grow down and wraps around to the top of the data segment, it will touch the area that isn't allowed in the segment. there some issues with the value of N, but i won't go into that. like so: +----------+ | heap | +----------+ | data/bss | +----------+ | stack | +----------+ this has the disadvantage of having to set the stack limit when you link the load module, but it will keep one from crashing into the heap. i don't think this is worth the effort. the second reason to turn on the segment protection is to make use of more of the memory in the system. you can have more than the six to eight processes. again, i don't think it's worth it, even thought is hard to `waste' that other 512M. anyway, again i'm sorry for the long message. if anyone has a better answer as to WHY intel designed the segments the way they did in protect mode, if you know what language they were thinking of, please let me know. bc 1011 1100 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-11-19 4:17 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-11-14 21:34 [TUHS] Redoing "V6on286" or porting V7...? Norman Wilson 2005-11-14 22:59 ` Brantley Coile -- strict thread matches above, loose matches on Subject: below -- 2005-11-09 17:26 Lyrical Nanoha 2005-11-09 21:54 ` M. Warner Losh 2005-11-09 22:03 ` Brantley Coile 2005-11-12 6:13 ` Albert Cahalan 2005-11-12 13:18 ` Brantley Coile 2005-11-13 20:16 ` Peter Jeremy 2005-11-14 9:38 ` Wesley Parish 2005-11-14 15:45 ` Brantley Coile [not found] ` <8a61b612cf43394f33e6531339fe4263@coraid.com> 2005-11-14 19:49 ` Peter Jeremy 2005-11-14 20:31 ` Brantley Coile 2005-11-16 21:41 ` Lyrical Nanoha [not found] ` <17277.62390.986234.433543@hod.localdomain> 2005-11-18 17:59 ` Lyrical Nanoha 2005-11-19 4:17 ` Brantley Coile 2005-11-15 3:08 ` Greg Haerr 2005-11-15 3:40 ` Peter Jeremy 2005-11-15 13:30 ` Brantley Coile
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).