[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some words of encouragement



> 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.)

Available memory was one issue (256KB is all you can easily count on,
512KB isn't stock, and more than that was generally a custom card).
But another problem is part of video memory needs to be located
somewhere in the first 256KB.  Maybe it's possible to make work but it
just doesn't feel right.

FreeDOS was pretty trivially easy to make run - all it needed was a
base/load address modification and it was good to go.  Well, that and
writing a BIOS (or ripping Sanyo's from the DOS 2.11 that came with
it, but that's not my style, except for the horrible, horrible little
floppy data transfer engine that arises from the lack of DMA).

> 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.

I keep forgetting this stuff is coming from C that assumes it can do
sane pointer arithmetic.  Some parts of my scheme were pretty much
assuming hand coded assembly with procedures written around the
windowing scheme.  (I was envisioning a sort of java-like programming
language where segments are selected when crossing "class" boundaries,
so it would be unlikely for a 64KB segment to be filled, except for by
really bad coding techniques).  But I feel my chances of implementing
something like that are slim.  But if I change it to the idea of
implementing a target for a "plain" compiler...

Anything that targets "normal" x86-16 with bigger than 64KB data
chunks needs to understand arithmetic on far addresses, and I wonder
how hard it would be to do some sort of virtual linearization here,
basically instead of a far pointer being effectively 20 bits of
address inside 32 bits of storage, just make them flat 32 bits.  Then,
calculating the segment address is either shifting around for the
"normal" case of 1MB space where the address really just is 20 bits,
or could be converted to an ABI call (some interrupt numbers range?)
for the OS to prepare memory and provide a segment address.  The
pointer arithmetic would reduce to plain 32 bit operations, but
dereferencing an address would be significantly more complex.  It
would be easy to make a compiler generate code, but would probably be
challenging to make a compiler generate fast code.

> 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.

Definitely a fair point.  My best counterpoint is that lots of these
earlier machines were built like tanks and I suspect they will still
be operable many decades from now.  But the less they're capable of,
the less chance they will be operating.

> 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.
>

There's lots of options for special applications to get access to
extra memory, but lots of programs of interest wouldn't be compatible
with this.  Porting things would be (even more of) a nightmare.

> 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.

This sounds like it'd be a good way to help ferret out bcc compiler
bugs or bypass them entirely, plus from what I've read, Watcom is one
of the better compilers to target 16 bit x86 in general.  There may be
some hints in FreeDOS, as openwatcom is one of the supported compilers
for the kernel there.
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Linux]     [Photo]     [Yosemite News]     Dell XPS 2720 wall mount     [Linux SCSI]     [Linux Hams]

Add to Google Powered by Linux