Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
rdos wrote:486 systems with APICs simply would not run most operating systems or applications of the time.
PICs and APICs are not mutually exclusive, and up until the introduction of legacy-free hardware, it was expected that any multiprocessor PC would have both.
rdos wrote:When the APIC was introduced, it had a PIC emulation mode that was default after boot.
When the APIC was introduced, it did not have PIC emulation. Separate PICs had to be present on the motherboard.
rdos wrote:There is a peculiarity about booting an AP core on a PC. Since it is the BIOS that gets control when you boot the AP, you need to tell the BIOS to jump to another location rather than the normal boot location. You do this by setting a byte in the CMOS RAM.
This only applies to very old hardware (486 and early Pentium). Anything newer than that will obey the STARTUP IPI.
rdos wrote:There is a peculiarity about booting an AP core on a PC. Since it is the BIOS that gets control when you boot the AP, you need to tell the BIOS to jump to another location rather than the normal boot location. You do this by setting a byte in the CMOS RAM.
This only applies to very old hardware (486 and early Pentium). Anything newer than that will obey the STARTUP IPI.
Yes, but IIUC, rdos has uses cases for supporting such older hardware; embedded management systems and Point of Sale systems tend to stay in use for a very long time. It costs time and money to replace such systems, often significantly more than it would for a business desktop system, and doing so disrupts normal business operation. Companies generally don't want to take something like that out of service until absolutely necessary. Thirty years is by no means out of the question, assuming the motherboard or CPU haven't died.
I don't know if any of the currently-installed RDOS systems are still running on such old hardware, but I wouldn't be surprised if some were.
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
rdos wrote:There is a peculiarity about booting an AP core on a PC. Since it is the BIOS that gets control when you boot the AP, you need to tell the BIOS to jump to another location rather than the normal boot location. You do this by setting a byte in the CMOS RAM.
This only applies to very old hardware (486 and early Pentium). Anything newer than that will obey the STARTUP IPI.
Yes, but IIUC, rdos has uses cases for supporting such older hardware; embedded management systems and Point of Sale systems tend to stay in use for a very long time. It costs time and money to replace such systems, often significantly more than it would for a business desktop system, and doing so disrupts normal business operation. Companies generally don't want to take something like that out of service until absolutely necessary. Thirty years is by no means out of the question, assuming the motherboard or CPU haven't died.
I don't know if any of the currently-installed RDOS systems are still running on such old hardware, but I wouldn't be surprised if some were.
SMP support is relatively new (about 10 years or so), and only was developped for newer processors with only APIC. Some of the systems indeed do run on older PCs (PIC-based), but none of those are SMP.
Octocontrabass wrote:
When the APIC was introduced, it did not have PIC emulation. Separate PICs had to be present on the motherboard.
By the time the APIC was invented (prior to being on the CPU die), the PICs had long been integrated into a single chip ("super IO"/"southbridge") along with virtually all the other ancillary PC motherboard hardware. The APIC was just added to the same chip. It's not really a case of one emulating the other as it is a completely different chip (almost certainly a micrcontroller running its own code) emulating both, regardless of how it's expressed in the specification...
