Theoretical: Why the original 386 design was bad

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Theoretical: Why the original 386 design was bad

Post by Solar »

rdos wrote:Interesting. It is claimed to be "OS independent", yet the source-code is C, and it clearly will not run easily in anyhing else than a 32-bit flat memory model. IOW, it is not OS independent since it won't work on OSes written i assembly, won't work on 16-bit OSes, and possibly won't work in a segmented environment.
Are really that full of yourself?

ACPI is of 1996 vintage. By that time, it was absolutely clear that everybody that mattered would be doing their operating system business in 32bit using high-level languages (which pretty much ruled out segmented memory too).

Everybody that didn't was simply not significant enough a market force to be considered in CPU design (or code examples).

ACPI can be, and is being, used by Linux, Windows, *BSD, and Apple. That is as "OS independent" as it gets these days.

I don't want to belittle your success with RDOS. You certainly had more success with your hobby than I ever had, and I applaud and envy you for it. But pointing fingers at CPU manufacturers because they don't cater for hobbyists and nostalgics is starting to get on my nerves.

If I had my way, Motorola would never have stopped the MC680x0 line, but they did. If you had had your way, AMD's x86_64 would still support segmentation, but it doesn't. Let's cope, ok?
Every good solution is obvious once you've found it.
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

Re: Theoretical: Why the original 386 design was bad

Post by rdos »

Solar wrote:ACPI is of 1996 vintage. By that time, it was absolutely clear that everybody that mattered would be doing their operating system business in 32bit using high-level languages (which pretty much ruled out segmented memory too).
By that time RDOS was already mature. :mrgreen:
Solar wrote: If I had my way, Motorola would never have stopped the MC680x0 line, but they did. If you had had your way, AMD's x86_64 would still support segmentation, but it doesn't. Let's cope, ok?
I am. I've dropped segmentation for applications, and the new prevailing device-driver model is a small, 32-bit, memory model that should be able to run both the ACPI C-code and some other highly portable code.
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: Theoretical: Why the original 386 design was bad

Post by Owen »

By the way: ACPICA will run on memory models other than "32-bit flat". For example, 64-bit flat. On IA-64.
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

i started to program on 386 :D i remember how everything looked very puzzling at that time to me, with the 'conventional memory', 'extended memory' 'high memory' 'paged memory', have lot of Mo of memory avaible that was not actually avaible to load tsr, and how it was all the time hell to make some game work correctly with the 640k of conventional memory and tsr, and how it would need to make special bootdisk almost for each game to load only the required tsr to have all the options, all in the meanwhile have some Mo avaible in 'higher memory'

i was only about 14 or 16 at that time, and i was only programming some bit of things in vga and pascal, but already the whole programming thing was very weird, with dos4gw extenders, and many different version of borland and turbo C/pascal, with handling of memory and 32 bit that could differ between the version , and lot of basics around as well, it was really another world from now, and i couldn't help to think the design was very unhomogenous, and puzlling how some ressource were made very hard to access from my point of view of beginner programmer of the time

and there was lot of commonly used 'hacks' like db 66h to use 32 bit opcode in the 16 bit real mode, and lot of things that were hard to figure out if you weren't connected to a very good source of informations, because processor were basically running by default in a mode that was not the most advanced mode, and as DOS relied heavily uppon the bios, and on real mode, the computer was still booted in real mode and the dos was still majoritarily working in real mode, and win3.11 just ate too much memory to be able to run any interesting game, and didn't provide any meaningull api or advantage over vga or vesa, and even office application were still running in text mode, the only meaningull game that was running on win3.11 was actually the warcraft 2 editor and it stayed like that for a long time, i can't think of even a single game that required win3.1 to work

when i look at what was going on at the same time on amgia, with an integrated blitter/copper, integrated sound chip, much easier to use and logical memory model, i can really understand why lot of people who were coding on amiga never switched to pc until very late, because pc was really a mess, but it's not only because of intel, ibm also made some mistake, like the way interupt/exeption were mapped were already supposed to a design flaw to begin with, there was never even any kind of decent for sound under dos, neither in the bios, and game progrmmer had to code themselve the drivers for all hardware that could be present, with autodection of the base addr/irq that was all the time failing lol compared as the design that was on c64 on amiga, it was still very weird thing

the only moment were dos and this whole system could have been really interestig is when C and 32 dos extender started to be common in the same time than glide and voodoo cards, but it's also when they *finally' moved massivly to the native 32 bit os like windows, but at that time, there were already a few game running under dos extender who could use 3D acceleration that was mind blowing, it's why i always keep in mind that implementing all the hardware acceleration must not be so hard and complicated in the bottom, at least in monotasking/full screen mode, as some game like jetfighter 3 could handle a bunch of 3D accelerated graphic card under dos without any os driver, and as all the os was running in 16 bit real mode, 32 bit extender program had about exclusive access to all the higher memory part and the protected mode

but it's more like a whole chain of mess and it's not only because of intel and 386, it's the whole pc architecture that was poorly designed from start, at least for multimedia, even the tsr system was not that much very advanced in term of design, it was purely mono task, mono user, without proper network or audio support, the only thing that saved the day was th vesa standard, and yet it was not that great compared to the hardware you could find on amigas, when i hear people who were really amiga programming guru, and the level of power you can reach using pure assembly, and the whole range of thing amiga could handle regarding handling of pallete, sprites, vbl, etc compared to what pc could handle in a standard manner, i can't help but to call the whole pc arch rather piece of crap, but ibm and microsoft are just buisness shark, and more buisness in mind totally than actually being geek and wanting to develop really programmer friendly or most efficient plateform, compared to engineer who designed amiga or c64

pc was very good for office like applications, and to provide a sort of rigid memory model to design simple application in secure and simple manner, dos was still pretty stable all together, i don't remember i had to reboot the comp following global crash under dos, on amiga it could be more frequent, on win95 well ahem lol

for me the major issue is that there never was a true 32 bit multi taking os for 386, in itself the 386 is not all that bad, but there was just so much of application base that used 16 bit real mode, many games as well, lot of games that were already port from amiga, that they just couldn't drop the compatibility, nobody would have bougth a new pc with 386 without even a proper os to use it's feature properly, basically you'd have to drop all the application base to still have the computer run in 16 bit real mode because they simply didn't have a real 32 bit multi tasking os that was suitable to develop games or advanced application, it would have been a very poor decision to do that, and so they dragged that for very long time, as most games and application were developped under dos with a 32 bit extender, and 32 bit extender cannot run in a true 32 bit multitaksing protected mode windowed OS either, so they were stuck with that

even the biggest commercial hit epic game of all time DOOM, used dos extender, it's still quite a shame when you think about it, how pc really lacked a true 32 bit protected mode multi tasked OS for barely 10 years to handle the 386 programming natively, and instead relied on dos extender, that messed up a lot the course of the design, i'm sure if they really had a well designed kick @$$ 32 bits multi tasking os at the time they released the 386, they could have been much more confortable with droping backward compatibility, but in the context, they just couldn't do that, as for most application, the pc architecture of the 386 didn't have much more to offer than the 286, and it would really have been shooting themselve in the balls to drop the compatibility
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

but actully the 386 was rather a very good design in many aspect, what you critics is more the whole part about backward compatibility and all that, but if you look at only at the part of things that 386 actually introduced , win 3.1 already implemented the whole 'modern' applicative context, with multi threaded paged memory, technically you could almost program application close to the modern way it is made today on win3.1, and this application model is the one used today in 95% of software made on the planet, so in that regard, 386 was still a major breakthrought

i never programed on ppc or 68k myself, but i know many people who do, and i often have the feeling that people who used to program on those cpu have a whole different view of what cpu improvement is supposed to be about, like about fast alu, improved instructon set, something mostly oriented on performance and hardware interfacing, and on this the pc 386 didn't offer much, but it was still a major improvement over 286 anytime, and still offered a very usable instruction set that didn't evolved that much until the pentium mmx

but basically dropping 286 compatibility would just have meant dropping dos and bios as a whole, and making win 3.1 the main os for the pc 386, and as i was rather active on the pc at that time, i can tell this for sure, there was absolutly nothing going on under win3.1 at that time

for professional game maker of that time, win3.1 was a bad choice because

1. complex specific new api that would need lot of learning for programmer
2. the whole overhead to have to deal with all the layer of windowing, gdi, graphic interface in C with zero graphic acceleration
3. many restriction on what is allowed to do and programming model compared to a dos extender

the only advantage would have been to have unified audio driver layer, which was not a big deal in itself cause all card were sound blaster compatible and not hard to deal with, and generally at that time game programmer prefer to initialize and deal with all the hardware internatlly rather than relying on a driver layer

so for most programmer, the win3.1 system was just not viable, specially in gaming industry, competion is pretty hard regarding performance and graphics, and developping game for win3.1 on 386 would just have been suicidal for any serious game programing company of that time

so the bargain of dropping 286 compatibility would have been pretty simple, loosing all the application basis to bet everything on a dos extender which is the only thing 386 pc could have to offer, which would have been a rather risked bet, it would be like nowday dropping all compatibility to switch to x64, which for most user is just some obscure nerdy thing related to cpu that doesn't change anything to the way the computer works, and even if it's quite radical evolution for programmers, for most end user it just mean nothing, and it's hard to ask user to buy a new architecture because it will be better archi for the future if there is no actual application on it at the time it's being sold, and that it will require some amount of time before it's really exploited

the smartest thing they could have been doing if they really wanted to make a total break starting from 386, would have been to make a sort of dos - like system, but in full 32 bit protected mode, so dropping the bios, and making dos a true modern like os, with drivers layer etc even a very light and old school driver api in assembler but that would make many design problem and would be a very broken architecture, but still maintaing the same context of application that a dos extender would provide, but that would be probably the most broken design that have ever been made that it was not even worth it

it would still have broken application compatibility, but at least giving a way for programmer to program efficient application in exclusive 32 bit protected mode, and just giving a bit of time to build a 32 bit cd rom application base and force all software company to totally drop completly the 16 bit flat model, but it would have left the 386 pretty useless for minimum a year the time that actuall good game and application are developped for it, and would have been much of a risky bet for ibm to loose all the software maker or that people just keep on the 286 because of all game and application present on it, and you could still program very decent thing even in 16 bit real mode at that time

386 was a good cpu actually in many aspect, but the world was just not ready for it, and they prefered to use it to run mostly 16 bit application and 16 bit os for a while, rather than forcing the pc to switch to fully mutli tasked environement that was just not mature enought at that time to provide competitive gaming framework, programmer only started to switch massivly to the style of programming implied by the 386 arch with win 95, when they started to implement directX, and full layer of drivers, that could initialize accelerated graphic and everything in 3 lines of directX

then it totally and completly outperformed anything that could even be expected to be done under dos, it was game over for dos totally at this point, and then it became really interesting for programmer to switch to this applicative model of full paged multi tasking, but before that time, which was mostly two generation of cpu after the 386 with the first pentium, it was just not viable to expect programmer to make full use of the 386 arch in the way it was intended, os were not mature enought, and frequency/memory too low to really allow for the whole layer overhead of such system , specially for rendering at time were memory was about 4Mo on 33mhz, expecting to program real time game application with a pure C/C++ api in a multi layered multi tasked environement without graphic acceleration was not realistic, but technically win3.1 and 386 already allowed for that
linguofreak
Member
Member
Posts: 510
Joined: Wed Mar 09, 2011 3:55 am

Re: Theoretical: Why the original 386 design was bad

Post by linguofreak »

h0bby,

This thread hadn't been posted to in two and a half years.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Theoretical: Why the original 386 design was bad

Post by bluemoon »

By the way, get a keyboard with functional cap-lock, shift, and full stop 8)
That could improve readability.

For very long post, you may also put an introduction, summary, or conclusion such that people grab your idea more easy before digging into detail, or most likely just skipped them (TL;DR;).
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

i don't care, i don't have a sleep mode fully implemented yet, and dos is not dead and it's more than 20 year old, so a thread is not dead unless it's older than internet, i could even resurect a thread on a bbs if i really wanted to :)
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

not but t's critical thing, think what you want, but why do you think you still have to write a boot loader in 16 bit flat mode in 2013 ? why do you think lot of linux package were still labeled i386 until even recently ?

dos programmer really know how a pc works, they are not like lame C unix programmer
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

if you think my post are long and boring, try to read an apci spec
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

rdos wrote:
quok wrote:As you said though, Intel provides a reference implementation called the ACPICA. More information about it is available at http://www.acpica.org/ and it even supports APCI 4.0a. (Which surprised me a bit, as for a long time it was stuck at ACPI 1.1 support only.)
Interesting. It is claimed to be "OS independent", yet the source-code is C, and it clearly will not run easily in anyhing else than a 32-bit flat memory model. IOW, it is not OS independent since it won't work on OSes written i assembly, won't work on 16-bit OSes, and possibly won't work in a segmented environment.

Possibly, with some effort, ACPICA might work as a 32-bit RDOS device-driver using Open Watcoms 32 bit segmented memory model with a single code and data segment. This makes for an interesting use of this new device-driver model.

EDIT: I've just confirmed that ACPICA compiles cleanly with Open Watcom, using a 32-bit segmented, small, memory model.

However, as I noted before, ACPI tables could exist without a BIOS, and regardless of the operating model and bitness of the BIOS. They are just tables, with some AML-code.
if you think about os in a conceptual level, rather than on call interface level, acpica is far from being os independant :)
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

Solar wrote:
rdos wrote:Interesting. It is claimed to be "OS independent", yet the source-code is C, and it clearly will not run easily in anyhing else than a 32-bit flat memory model. IOW, it is not OS independent since it won't work on OSes written i assembly, won't work on 16-bit OSes, and possibly won't work in a segmented environment.
ACPI can be, and is being, used by Linux, Windows, *BSD, and Apple. That is as "OS independent" as it gets these days.
acpica can be ported on any os, it's portable, inter operable, but it's not os independant.

a library that explain you into the doc how you can hook a call back to access i/o ressource right into your device drivers, and make this a requirement to implement it correctly can hardly be told to be 'os independant' that's a joke

intel acpi need your os to support it, it's actually entierly dependant on your os

i mean just make a functional diagram, put your os on a side of the diagram, and apcica on other side, and then see how 'as os independant as it can get' apcica really is (hint an arrow to connect the functionality mean it has a dependency)

even aml doesn't seem to be os independant as it implement some function that need synchronous communication with the os (like notify events) acpica say some of those code block can block until they recieve a return value from an event, and of course event hanlder and notify event are supposed to be handled in your os

and even the first call you should be doing to initialize apci is to setup your os version with the _osi method, so yeah clearly it's totally as os independant as it can get, no kidding

i would run this in vm086 mode as it's so much os independant, but it doesn't seem it's supposed to be operated that way
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

Re: Theoretical: Why the original 386 design was bad

Post by rdos »

h0bby1 wrote: if you think about os in a conceptual level, rather than on call interface level, acpica is far from being os independant :)
Yes, and ACPI is also a piece of junk that major software and hardware manufacturers put out just to confuse competitors. Today it is close to useless, and once all PCI devices have MSI-support (which will be soon), we no longer need it for anything else than the power-button. Intel have even started not support power-management on their CPUs with ACPI because they don't provide the necessary objects, but instead require the use of their own code which of course is only available to some selected OS manufacturers.

So any new OS-design primarily based on ACPI is already obsolete. If you have ACPI-support, you have it as an insignificant device-driver service that tells you the IRQ of an PCI-device that lacks MSI support.
rdos
Member
Member
Posts: 3297
Joined: Wed Oct 01, 2008 1:55 pm

Re: Theoretical: Why the original 386 design was bad

Post by rdos »

h0bby1 wrote: and even the first call you should be doing to initialize apci is to setup your os version with the _osi method, so yeah clearly it's totally as os independant as it can get, no kidding
That's one of the big problems with ACPI. You don't pass your os and version to ACPI, you pretend to be some Windows version, otherwise you will not get the correct settings.
h0bby1
Member
Member
Posts: 240
Joined: Wed Aug 21, 2013 7:08 am

Re: Theoretical: Why the original 386 design was bad

Post by h0bby1 »

rdos wrote:
h0bby1 wrote: and even the first call you should be doing to initialize apci is to setup your os version with the _osi method, so yeah clearly it's totally as os independant as it can get, no kidding
That's one of the big problems with ACPI. You don't pass your os and version to ACPI, you pretend to be some Windows version, otherwise you will not get the correct settings.
yeah, to be accurate in the semantic, it's more correct to say it has a broken dependencies on the os, because the actual api to interface between the acpi system and the os is not very well done, it's kept to very low level functionality whereas an os should be more aware of what is actually implemented in the aml to carry the execution of it in a smarter manner, maybe it's more the aml interpreter of acpica that could improved

i'm currently figuring out if i want to implement it to which extent and how, if i want to only work with the lowest level of the acpica aml parser/interpreter, like working from the base of the disassembler and rewriting a large part of the execution framework, or use another parser system in edk 2 they seem to have another version of an aml interpreter that seem much smaller it's made by intel also under bsd license, maybe i'll work from that,but it doesn't seem to support all the execution framework that acpica provide, and acpica has been tested a lot to run buggy code, or maybe i'll skip it all, i don't really care about the power managment that much

maybe they should have left the choice of the acpi os name to user, and create different configuration with a better functional base for the naming
Locked