Re: Some words of encouragement

[Jody Bruchon <jody@jodybruchon.com>]

On 02/24/12 12:26, Brad Normand wrote:
> I've been watching this list for a while and I'm happy development is
> continuing!  The last time I tried playing around with ELKS, I
> couldn't even get things to compile, and had I succeeded, I got the
> feeling I wouldn't be too impressed.
You probably still won't be impressed. ELKS in my QEMU frequently goes 
into an endless loop or otherwise stops working properly. I'll work out 
the problem eventually, but in the meantime I'm trying to clean up the 
code. ELKS really needs to be more comment-heavy in the code. I'm tired 
of seeing one-letter variables everywhere and not being fully sure what 
they're up to.
> In case anyone's interested, my wishlist:
>
> Support for 100% BIOS I/O (eventually I'd like to run this on
> non-standard hardware, Sanyo MBC-55x, so any in/out opcode and
> interrupt hooking will fail to work as intended).  Where necessary,
> BIOS RAM can be probed and this shouldn't be a big problem.
I think there's some degree of this already. I know ELKS can be built to 
not disable IRQs at boot, and uses BIOS calls for most disk I/O anyway.
> Support for reserving some low memory area (again due to hardware constraints).
That shouldn't be hard.
> Some method to transfer data to/from FAT12.
Planned for the future, for sure. The FAT filesystem options in ELKS 
were "unimplemented features" so I stripped them out of the build 
process entirely until a driver actually exists.
> And, a question... how feasible would it be to run anything with 256KB
> RAM?  I was tempted to reply to the EMS code message because to make a
> useful ELKS machine out of these, I may have to design a memory
> expansion board, and I've got lots of 4MB SIMMs laying around.
> Otherwise without kernel bankswitching support (or through EMS calls)
> I believe I can do 960KB.
The problem with EMS code is that ALL EMS boards are different, and the 
LIM EMS specification is useless since it relies on the vendor-supplied 
DOS driver to work. We can write an EMS driver if we have the hardware 
and can figure out how it works, or if you make the hardware yourself as 
you suggest. EMS is extremely hard to find (particularly at a sane 
price) these days so I blew the whole idea off.
> I also have a strange memory management idea that may be
> interesting...  Since 8086 is a 64KB segment oriented machine and you
> are already bumping up against the limitations of that, and there is
> talk of changing compilers...  how crazy would it be to design a new
> segmentation ABI to allow relocation of segments and still allow
> programs to use more than 64KB?
Manpower is always the issue. My thoughts (which I have not shared until 
now) were the same as what I was doing with my 6502 operating system 
that I've written: each program has a set of relocation tables that are 
just a list of offsets to absolute pointers (far pointers on 8086, long 
addresses on other platforms we might support later like 65816) and when 
the application image is loaded into memory, the relocation tables are 
retained in memory as well. 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. This could even potentially be used to move data that is 
malloc()ed around if it was done carefully. But, of course, we come back 
to the issue of manpower once more. Who is going to write the compiler 
code that generates these new executables, the ELKS code that handles 
the new executable format, etc.? From what I understand, a lot of the 
people with sufficient compiler knowledge bailed on ELKS some time ago, 
so making this change would be an uphill battle.
> I'm thinking something along the lines of, instead of using mov DS,AX
> type instructions, these are changed to an OS call, so that the kernel
> knows what segments the userspace is using, and when it has to
> relocate data, it can simply rewrite the stored CS,DS,ES,SS of the
> userspace, and next time the userspace needs to switch segments, it
> asks the OS to do the dirty work.  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.
That sounds plausible, but I'm guessing bcc doesn't generate MOV DS,AX 
anyway, since it apparently restricts everything to single segments...
> Sorry for the craziness but I've spent many hours pondering this stuff
> in the past...  if there's interest I'd be happy to put together a
> specification of sorts.
Right now, we need to fix the most egregious bugs in the code, 
specifically the ones that cause the system to hang, lock up, get stuck 
at a looping "login:" or other crashy behavior. I suspect that bcc is 
partially responsible for some of these problems, given that it 
generates lackluster code and the bcc source itself is very poorly 
documented, making changes to it dicey. 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'm thinking that the only real solution is going to be 
to either massively retool bcc, or to write a compiler. I'm starting to 
see why ELKS was abandoned; few people exist that want to do these big 
jobs AND possess the requisite experience to actually do it.

Jody Bruchon