Re: Would you use a native 32/64-bit FreeDOS/BIOS system?
http://sourceforge.net/u/udocproject/profile/
I have written a few Assembly code snippets that will be helpful. I should
probably talk in the development list to see how to think up 32/64-bit native
implementations.
For example, I have a project called x86 Portable, which allows to reuse the
exact same assembly code across 16/32/64-bit modes. It is done by simply
defining register-width-dependent data types like wideword, which will become
16, 32 or 64-bit in size according to the target CPU mode.
It also includes portabilized assembly functions like movswide which will
translate into movsw, movsd or movsq depending on the target CPU mode.
That project can be very valuable to implement FreeDOS/BIOS portably across 32
and 64 bits.
I've also thought that to make the system even more portable, only fully
standard C language features should be used so that the code can be compiled
with Borland, GCC, Open Watcom or Visual Studio, and at most C++, but using
only what could be considered old C or C++, because it will be needed to make
the system portable across compilers to make it easily self-compiling.
The original FreeDOS could be used as the boot loader with a shell as long as a
machine has a BIOS, and it in turn could be used to start the 32 or 64-bit
system, and also will work for being able to return from 32, and maybe 64-bit,
back to FreeDOS in Real Mode.
Multitasking and protection could be loaded modularly since it's DOS and it
would work as an operating system that allows full access to the machine, so
more complex or protective features would probably be better implemented as
container applications, layers, drivers, modules, but not forcefully always
loaded by default.
Talking about development, implementing FreeDOS for 32 and 64 bits natively
could be relatively simple, apart from the work of adapting and writing
portable C code that only uses simple language features present in all versions
of the language.
For example, providing DOS-style structures, DOS and BIOS calls, would only be
a matter of extending all fields, from 8 or 16 bits, to always the register
width of the target CPU mode.
For example if a BIOS field is now 8 bits, for example for CHS or LBA, in the
32-bit version it would need to be 32-bit and 64-bit for the 64-bit version,
unless things like handling wider fields in software or with the FPU is
integrated in the OS.
In the case of disks, the LBA value would need to be up to 48 bits, or 28 bits,
because that's what the ATA standard says, so software would need to be able to
handle 48-bit integers for disks, and probably there will be other cases where
32-bit code will need to handle numbers bigger than 32-bit in software.
That would be the basic idea, extending small fields to the full register width
portably. It will surely allow using the same style of BIOS/DOS calls for
example for much bigger LBA or CHS values.
So the current FreeDOS could be used to boot and to return from 32/64-bit
modes, and 16-bit programs could be virtualized while running in 32/64-bit
mode, so it would be useful.
It would be a matter to dedicate 1 year for each key task in the system per
developer or sub-group of developers.
I've proven to myself that it would be a very fast way to investigate and have
ready things like better IDE/SATA detection, implementing file systems,
networking, support for running native vendor drivers, the core base
implementation to 32/64-bit; each of those things taking 1 year to be well
implemented into FreeDOS, if possible, with sub-teams working in parallel to
get more features.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
