On 24/02/12 18:22, Jody Bruchon wrote: > On 02/24/12 12:26, Brad Normand wrote: [...] >> In case anyone's interested, my wishlist: FWIW, I believe Minix 2 meets at least some of your requirements. If you're interested in tiny Unixalikes, it's well worth checking out: http://www.minix3.org/previous-versions/Intel-2.0.4/ (Although if you really want to run it on an XT, you'll need 2.0.3. 640kB isn't quite enough for 2.0.4.) [...] > If we needed to shuffle code elsewhere in > memory for whatever reason (EMS, swap, defragmenting memory, loading a > distinctly separate instance of a program already being executed, > something to do while setting the building on fire) it would be a simple > matter of enhancing the memory manager to intelligently rewrite > relocations and tweak the stored task processor context to match the > changes. As it stands this will only work on the text segment, of course. We don't know the layout of the data segment, so are unable to relocate pointers in it. (Because we don't know what addresses contain pointers.) This is where the half-baked 8086 'MMU' actually comes in handy; all memory accesses are relative to SS, DS or CS, so moving stuff around in memory is trivial. If you don't have segments, and are on a flat memory architecture, then there are two approaches: (a) don't relocate data, just relocate text. (b) fake segments by reserving a register to point at the data segment base, and then do indirect accesses from that. I have a faint memory that Minix 68k does this (b). But it's slow, of course, as you need to make sure that only relative addresses are stored in memory, because storing absolute addresses would break relocation, and you need some way to distinguish between absolute and relative addresses in registers... My opinion is that the 8086 is so limited and so intrinsically slow and, well, crap, that trying to handle anything bigger than 64kB code + 64kB data isn't worth the hassle. >> Managing>64KB allocations is >> possible too but basically the program needs to request a 64KB window >> into the data at a time. This would probably be pretty directly >> applicable to a bankswitching scheme as a poor man's MMU. It would be relatively trivial to add the ability to allocate extra chunks of data which are then accessed via read/write-like functions. extern int mmapalloc(int size); // returns handle to new block extern int mmapfree(int size); // returns handle to new block extern void mmapread(int handle, void* buffer, int offset, int length); extern void mmapwrite(int handle, void* buffer, int offset, int length); mmapalloc() and mmapfree() would allocate a new segment. mmapread() and mmapwrite() would be tiny little pieces of code that would just load the segment descriptor into ES and do a bulk copy with REP STO or something. That might be useful for certain specialist operations but, again, if you need that much memory, you probably shouldn't be using an 8086... [...] > Once again, I would love to > switch compilers, but while SDCC is apparently the most promising > option, it also doesn't support the 8086 (unless I missed something when > I looked at it), so that's a dead end unless someone wants to port SDCC > to 8086 first. I do actually have Watcom *almost* generating ELKS executables. No libc, of course, I'm simply fighting the linker (which is deeply bizarre), but it is getting there. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Never attribute to malice what can be adequately explained by │ stupidity." --- Nick Diamos (Hanlon's Razor)
Attachment:
signature.asc
Description: OpenPGP digital signature
