OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 1:59 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Fri Mar 31, 2017 3:45 pm 
Offline
Member
Member

Joined: Wed Jul 18, 2007 5:51 am
Posts: 170
Korona I may have to disagree with your statements....

Quote:
And much less reliable and forward compatible.

Wrong statement as shown by answers below.

Quote:
How do you enumerate PCI root complexes? We already have NUMA systems with multiple PCI roots.

The PCI Host Bridge device has the 'MCFG' table in it's Configuration Space. Much more simpler and reliable than the bloated disaster known as ACPI.

Quote:
Plus there are devices that fundamentally cannot be part of the PCI, for example VT-d and persistent memory DIMMs.

VT-d could be represented by a standard PCI device. Any attempt to map the VT-d PCI device to a virtual machine would throw an error :)
Memtest86 / Linux can already get RAM SPD information. I would guess it's not difficult to expand SPD information to include a "Persistent Memory" flag.

Quote:
It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC.

I/O APIC is not a "legacy" device, you go that wrong.
If IBM PC/AT compatibility isn't required then legacy chips can be removed and everything is enumerated via PCI bus. ACPI/AML is total overkill.

Quote:
You need some mechansim to enumerate and relocate devices on the system bus.

The mechanism is the PCI Configuration space.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Fri Mar 31, 2017 6:22 pm 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 595
The route that computers are taking today is having a power management CPUs (PMU). The CPU used for this is typically a ARM Cortex M3 or even simpler microcontroller. In order for the OS to interact with the PMU is having a defined message format and an IPC method between the "normal" cores (x86, ARM or whatever) and the PMU. While PMUs is usually only for handling power related functions and interrupt routing, I see no problem that this could also be extended for PCI functionality as well. In practice I think that this method is a better way than the ACPI AML method and you simply don't need these byte code clones which just bogs down your OS. It wasn't that common in the 90s to litter small microcontrollers all over the system so I guess ACPI made more sense then. Today it's completely different, your cell phone has probably more small Cortex M3 microcontrollers than "big" ARM cores.

Another problem with ACPI is if it is suitable for how power efficient systems work. It works for desktops but for systems like cell phones you need a more flexible system. Typically in these systems you go for a full power off of the main CPUs and just retain the memory. When an interrupt comes you need to boot the CPUs and you need to do it fast in order to reduce interrupt latency and the question if ACPI is suitable here. We don't want one second like your laptop waking from S3 sleep. Also, you might want to keep the power for some units while powering off the CPUs and the question is how ACPI can handle this. I'm not an expert on ACPI so anyone feel free to explain what possibilities you have with ACPI for these scenarios.

ACPI AML was actually the reason I gave up on x86. It was too messy and slowed me down from what I actually wanted to do which is creating an operating system. I moved over to ARM systems as the development platform and I haven't looked back since.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 5:06 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
Brendan wrote:
Korona wrote:
It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC.


No it doesn't. For legacy devices you only really need a "present or not" flag in some kind of table (e.g. ACPI's "FADT") and don't need AML.

I don't think a simple present/not present flag would be sufficient. At the very least you'd need a "this legacy device is implemented in that LPC chip" table. And then you would need a separate power management driver for each LPC chip. If Intel/AMD at some point in the future decides to move more functionality onto their LPC chips then you'd have to update your driver in order to not lose the PM capabilities of already existing devices.

tom9876543 wrote:
Quote:
How do you enumerate PCI root complexes? We already have NUMA systems with multiple PCI roots.

The PCI Host Bridge device has the 'MCFG' table in it's Configuration Space. Much more simpler and reliable than the bloated disaster known as ACPI.

MCFG is not sufficient to enable/disable/remap root complexes. Also: MCFG is not part of the PCI configuration space. It's an actually an ACPI table so I don't understand how that proves that ACPI is bloated. If your argument is "only the AML parts of ACPI are bad" then I already agreed with that.

tom9876543 wrote:
Quote:
Plus there are devices that fundamentally cannot be part of the PCI, for example VT-d and persistent memory DIMMs.

VT-d could be represented by a standard PCI device. Any attempt to map the VT-d PCI device to a virtual machine would throw an error :)

I don't see how crippling and complicating actual hardware because your firmware lacks a proper discovery and configuration mechanism makes any sense. It's much easier to provide a proper configuration mechanism in software (i.e. the firmware/BIOS/EFI/whatever) than to make every hardware behave as a PCI device when it isn't actually a PCI device. Also: How do you handle memory or CPU hotplug? Do you pretend that memory DIMMs and CPUs are part of the PCI?

EDIT: The more that I think about it I get the impression that ACPI is actually a good thing for hobby OSes. Without ACPI you'd have a driver for every proprietary power button/fan/LPC/SMBUS controller out there to get power management working. That wouldn't be a problem with mainstream OSes because hardware vendors do bother to write drivers for them. It would make things easier and simpler for them because they wouldn't have to run foreign code. However it would be a massive problem for small OSes.

EDIT2:
tom9876543 wrote:
Quote:
It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC.

I/O APIC is not a "legacy" device, you go that wrong.
If IBM PC/AT compatibility isn't required then legacy chips can be removed and everything is enumerated via PCI bus. ACPI/AML is total overkill.

Yes, the I/O APIC is a legacy device. On modern systems its only use is to route legacy PCI interrupts. Modern devices exclusively use MSI as that is demanded by the PCIe spec and has much lower overheads and much cleaner semantics (no mandatory level triggered IRQ crap). Also: How do you determine that your host does not contain legacy devices if there is no discovery mechanism for them?

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 10:14 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Shall we start effusively praising ACPI now? 'Cos I would say that ACPI was made for this day.

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


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 10:21 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Korona wrote:
Brendan wrote:
Korona wrote:
It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC.


No it doesn't. For legacy devices you only really need a "present or not" flag in some kind of table (e.g. ACPI's "FADT") and don't need AML.

I don't think a simple present/not present flag would be sufficient. At the very least you'd need a "this legacy device is implemented in that LPC chip" table. And then you would need a separate power management driver for each LPC chip. If Intel/AMD at some point in the future decides to move more functionality onto their LPC chips then you'd have to update your driver in order to not lose the PM capabilities of already existing devices.


There is only ever one LPC chip and it doesn't make sense to have (e.g.) multiple pairs of PIC chips or multiple PIT chips or... No software has no reason to care where these devices are (you only ever need to care about the legacy IO ports that they used decades ago). The legacy devices do not have any power management, and are so slow and so simple that they consume almost no power and therefore will never need power management. By definition, the legacy devices can not be changed (if you decided to change a legacy device it would not be a legacy device anymore). ACPI already has a simple present/not present flag for legacy devices and nothing else; so continuing to have a simple present/not present flag for legacy devices and nothing else can not cause problems that don't already exist.

Korona wrote:
EDIT: The more that I think about it I get the impression that ACPI is actually a good thing for hobby OSes. Without ACPI you'd have a driver for every proprietary power button/fan/LPC/SMBUS controller out there to get power management working. That wouldn't be a problem with mainstream OSes because hardware vendors do bother to write drivers for them. It would make things easier and simpler for them because they wouldn't have to run foreign code. However it would be a massive problem for small OSes.


Nonsense. Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with. We'd also be able to use some parts (e.g. fan control) without touching or caring about completely unrelated things (e.g. laptop battery levels), which is something that can't be done with ACPI (which is "all or nothing" - either you enable "ACPI mode" or you don't). This alone would make it significantly easier for small OSs, because you'd be able to add support for what you want when you want to (instead of having to deal with many MiB of bloat when the only thing you care about is power button state and nothing else).

Could you imagine if CPU designers said "LOL, we couldn't be bothered having a standard for paging structures, use AML to setup page tables, etc"? It would be completely retarded (compared to having a small number of "standard paging structures" to support). In exactly the same way; (e.g.) "LOL, use AML for CPU speed control" is completely retarded now (compared to having a small number of "standard CPU speed control MSRs" to support), and (e.g.) "LOL, use AML for fan speed control" is completely retarded now (compared to having a small number of "standard fan controller devices" to support) and (e.g.) "LOL, use AML to turn the computer off" is completely retarded now (compared to having a small number of "standard power supply control devices" to support).

Korona wrote:
Also: How do you determine that your host does not contain legacy devices if there is no discovery mechanism for them?


Nobody is saying "have no static tables" or "have no discovery mechanism". We are only saying "have no AML".


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 12:03 pm 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
Brendan wrote:
Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with.


I agree with pretty much everything else you've said, but it's just as possible that we'd end up with thousands of different variations on power management hardware and we'd need special drivers for every chipset/motherboard. I'd hope it would go in the "tiny number of simple devices" direction, but I have very little confidence that it would actually be that way.

It's really hard to tell what happens in alternative universes.

_________________
Image


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 2:02 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

mallard wrote:
Brendan wrote:
Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with.


I agree with pretty much everything else you've said, but it's just as possible that we'd end up with thousands of different variations on power management hardware and we'd need special drivers for every chipset/motherboard. I'd hope it would go in the "tiny number of simple devices" direction, but I have very little confidence that it would actually be that way.

It's really hard to tell what happens in alternative universes.


Motherboard/chipset designers know that not complying with existing standards (including creating new standards) means lost profit, because old OSs won't support it and current OSs probably won't support it quickly enough (e.g. "unsupported at product launch"). This is why legacy devices (RTC/CMOS, PIC chips, etc) existed without change for about 30 years, why HPET hasn't changed for a decade, why there's only 4 kinds of USB controller, why there's only one kind of SATA controller (AHCI), etc. It's also why it's taken so long for UEFI to replace BIOS, and (unfortunately) why nobody has been willing to replace ACPI.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 5:33 pm 
Offline
Member
Member

Joined: Wed Jul 18, 2007 5:51 am
Posts: 170
Korona wrote:
tom9876543 wrote:
Quote:
How do you enumerate PCI root complexes? We already have NUMA systems with multiple PCI roots.

The PCI Host Bridge device has the 'MCFG' table in it's Configuration Space. Much more simpler and reliable than the bloated disaster known as ACPI.

MCFG is not sufficient to enable/disable/remap root complexes. Also: MCFG is not part of the PCI configuration space. It's an actually an ACPI table so I don't understand how that proves that ACPI is bloated. If your argument is "only the AML parts of ACPI are bad" then I already agreed with that.

Now you change the question from "how do you enumerate" to "how do you disable/enable/remap".
I would think this could be implemented by memory mapped io on the PCI Host Bridge.

Korona wrote:
It's much easier to provide a proper configuration mechanism in software (i.e. the firmware/BIOS/EFI/whatever) than to make every hardware behave as a PCI device when it isn't actually a PCI device.

Is it "much easier"?? You haven't provided any evidence.
If it requires an 100,000 extra transistors to make VT-D a hardware implementation with standard PCI discovery and simple memory mapped io, I would suggest that is a very beneficial tradeoff.

Korona wrote:
Also: How do you handle memory or CPU hotplug? Do you pretend that memory DIMMs and CPUs are part of the PCI?

As I stated in previous message, DIMMS have an SPD standard for identification. I'm not familiar with how exactly SPD works.
CPU hotplug should be managed by the PCI Host Bridge. The PCI Host Bridge can raise an interrupt when a CPU is removed / added.

Korona wrote:
Yes, the I/O APIC is a legacy device. On modern systems its only use is to route legacy PCI interrupts. Modern devices exclusively use MSI as that is demanded by the PCIe spec

OK I guess it depends on the definition of "legacy". I was thinking a standard PCI slot is not a "legacy" device, but maybe it is.

Korona wrote:
Also: How do you determine that your host does not contain legacy devices if there is no discovery mechanism for them?

The IBM PC/AT has already has a discovery mechanism - it is the Bios Data Area (BDA). BDA (and/or EBDA) should be extended to provide a very very simple table for legacy device discovery. I'm not sure how UEFI works, but it could have a "Retrieve Legacy BDA / EBDA option" for discovering legacy devices.


I agree with Brendan's statements. In an ideal world almost everything would be managed by a standardised PCI interface.
SATA disk drives -> AHCI PCI standard = SUCCESS
USB 3.0 -> xHCI PCI standard = SUCCESS
power management -> ACPI = DISASTER

Here is more evidence that ACPI is a pile of cr$p....
http://www.linuxplumbersconf.org/2013/ocw/sessions/1497


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sat Apr 01, 2017 6:02 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
tom9876543 wrote:
Korona wrote:
Yes, the I/O APIC is a legacy device. On modern systems its only use is to route legacy PCI interrupts. Modern devices exclusively use MSI as that is demanded by the PCIe spec

OK I guess it depends on the definition of "legacy". I was thinking a standard PCI slot is not a "legacy" device, but maybe it is.


It's something of 'receding horizon' issue; eventually, most things in a field that is still changing rapidly become 'legacy' as newer hardware is developed, but at any given time 'current' is going to be a range of hardware from slightly different generations. I would say that standard PCI isn't quite legacy yet, but is just reaching that point, and for most newer hardware (less than, say, five years old) it is already there.

(Note that I said 'in a field that is still changing rapidly'. Even in the current world, many fields don't change much over a period of decades - housing, for example - and historically, most rates of change could be measured in centuries. Sooner or later - and I think it will be sooner than most expect - the rate of change in computer hardware and software is going to drop precipitously. Even now, it is far slower than it was in 1977, or even in 1997.)

So for a new OS, it is less a matter of what is and isn't legacy, as it is of how far back you want to support. For existing systems? They have support for older hardware already, so it becomes a matter of how long they have to continue supporting existing systems that have been or are being superseded, instead.

Pardon me for a moment while I get this soapbox out...

Most people working in the field don't really get that for most people who aren't in the field - especially outside of the US, Western Europe, Australia, and the more industrialized Asian nations such as Japan, Taiwan, or South Korea (plus some of the more developed urban areas of mainland China) - having hardware that is over 5 years old is the norm rather than the exception. It is often even worse in the business world, and worse still in the public sector - I've been asked to maintain 10+ year old hardware more times than I care to remember by managers in both corporate and government offices, and in NPOs, twenty year old systems aren't unheard of even in the US.

In the US, most of the people who have new computers are ones who don't really care what they've got so long as they have the latest and greatest, whatever that is - and are likely to throw away the one they bought the year before, and replace it with an even newer one, rather than get someone to unclog their register and clean out the heavy loads of viruses and spyware they've accumulated in a year of careless use. But that's a minority of users; most have a smartphone from two or three generations back, and maybe a tablet and/or game console of the same vintage, but have never had a desktop or laptop PC of their own anyway (and wouldn't want one - they associate them with their jobs and classrooms, as something to escape from rather than bring into their homes).

Performance? Not really an issue - their hardware gets overwhelmed with malware faster than they could remove it, even if they knew how to or even really understood that it can be. To most people, having a new phone or tablet that runs at the same speed as their old one a week after they've turned it on for the first time is normal. The idea that something is wrong with a system when it gets like that just doesn't even occur to them. Why buy a new machine if it doesn't work any better than the one they have, especially since they can't afford it?

The point is, as enthusiasts, we don't really get that the average user wants something that is closer to a toaster, or at most a car, than to what most of us are looking for. They don't care how new it is, as long as it gets what they need done and they don't have to learn anything new to do it.

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


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sun Apr 02, 2017 5:14 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
Schol-R-LEA wrote:
Shall we start effusively praising ACPI now? 'Cos I would say that ACPI was made for this day.

:D I'm not a fan of ACPI at all; I'm just trying to point out that it's always easy to cry about things that you don't have to design yourself.

Hi Brendan,
Brendan wrote:
Korona wrote:
Also: How do you determine that your host does not contain legacy devices if there is no discovery mechanism for them?


Nobody is saying "have no static tables" or "have no discovery mechanism". We are only saying "have no AML".

Actually tom9876543 was saying just that: His premises were that interrupt routing should be static (as in "not configurable via software or fimware") and that PCI enumeration ought to be enough for everything. As such most of my post was responding to that. I agree with most of your technical points; I'm just not sure I trust hardware companies to settle on a small set of generic standards for things like fans and power buttons.

Brendan wrote:
There is only ever one LPC chip and it doesn't make sense to have (e.g.) multiple pairs of PIC chips or multiple PIT chips or... No software has no reason to care where these devices are (you only ever need to care about the legacy IO ports that they used decades ago). The legacy devices do not have any power management, and are so slow and so simple that they consume almost no power and therefore will never need power management. By definition, the legacy devices can not be changed (if you decided to change a legacy device it would not be a legacy device anymore). ACPI already has a simple present/not present flag for legacy devices and nothing else; so continuing to have a simple present/not present flag for legacy devices and nothing else can not cause problems that don't already exist.

I'm not so sure if there is only ever one LPC chip in modern systems. I could imagine that e.g. ATA emulation and PIC emulation are configured via different PCI functions. ACPI does define power management (mostly binary on/off PM) for some of the legacy chips though. You could of course define architectural PM for LPC chips to replace that without AML.

Brendan wrote:
Nonsense. Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with. We'd also be able to use some parts (e.g. fan control) without touching or caring about completely unrelated things (e.g. laptop battery levels), which is something that can't be done with ACPI (which is "all or nothing" - either you enable "ACPI mode" or you don't). This alone would make it significantly easier for small OSs, because you'd be able to add support for what you want when you want to (instead of having to deal with many MiB of bloat when the only thing you care about is power button state and nothing else).

That is true if hardware vendors actually settled on a small number of standards for PM controls.

Brendan wrote:
Could you imagine if CPU designers said "LOL, we couldn't be bothered having a standard for paging structures, use AML to setup page tables, etc"? It would be completely retarded (compared to having a small number of "standard paging structures" to support). In exactly the same way; (e.g.) "LOL, use AML for CPU speed control" is completely retarded now (compared to having a small number of "standard CPU speed control MSRs" to support), and (e.g.) "LOL, use AML for fan speed control" is completely retarded now (compared to having a small number of "standard fan controller devices" to support) and (e.g.) "LOL, use AML to turn the computer off" is completely retarded now (compared to having a small number of "standard power supply control devices" to support).

Agreed.

Let's move on to tom9876543's post:
tom9876543 wrote:
Korona wrote:
MCFG is not sufficient to enable/disable/remap root complexes. Also: MCFG is not part of the PCI configuration space. It's an actually an ACPI table so I don't understand how that proves that ACPI is bloated. If your argument is "only the AML parts of ACPI are bad" then I already agreed with that.

Now you change the question from "how do you enumerate" to "how do you disable/enable/remap".
I would think this could be implemented by memory mapped io on the PCI Host Bridge.

I don't have to point out that this is a non sequitur, right? You didn't explain how enumeration should be done. Enabling/disabling/remapping are just additional problems that you have to solve. Of course you have to explain enumeration first. Besides: Letting the host bridge configure itself seems like a bad idea doesn't it?

tom9876543 wrote:
Korona wrote:
It's much easier to provide a proper configuration mechanism in software (i.e. the firmware/BIOS/EFI/whatever) than to make every hardware behave as a PCI device when it isn't actually a PCI device.

Is it "much easier"?? You haven't provided any evidence.
If it requires an 100,000 extra transistors to make VT-D a hardware implementation with standard PCI discovery and simple memory mapped io, I would suggest that is a very beneficial tradeoff.

WTF? I'm not sure if the entire VT-d implementation needs 100'000 transistors at all. You certainly don't want to increase hardware complexity because some random OS developer is too lazy to support a proper discovery/configuration mechanism.

tom9876543 wrote:
Korona wrote:
Also: How do you handle memory or CPU hotplug? Do you pretend that memory DIMMs and CPUs are part of the PCI?

As I stated in previous message, DIMMS have an SPD standard for identification. I'm not familiar with how exactly SPD works.
CPU hotplug should be managed by the PCI Host Bridge. The PCI Host Bridge can raise an interrupt when a CPU is removed / added.

PCI should have absolutely nothing to do with CPU hotplug. There is no reason to pretend that CPUs or other devices are PCI devices when they are not. PCI is a bus and not a generic device discovery/configuration mechanism. It does not make sense from a technical point of view and it makes even less sense from a logical point.

tom9876543 wrote:
Korona wrote:
Also: How do you determine that your host does not contain legacy devices if there is no discovery mechanism for them?

The IBM PC/AT has already has a discovery mechanism - it is the Bios Data Area (BDA). BDA (and/or EBDA) should be extended to provide a very very simple table for legacy device discovery. I'm not sure how UEFI works, but it could have a "Retrieve Legacy BDA / EBDA option" for discovering legacy devices.

The EBDA is a joke as a configuration mechanism. You certainly need some sort of table that allows generic identifiers and resource (e.g. decoded address and I/O space) records unless you want to be locked to PCI forever (until you replace your entire system bus device discovery/enumeration standard). Additionally you want some ability to relocate devices on the system bus, e.g. in case the BIOS fúcks up and does not reserve enough address space for a bridge. And remember that the BIOS fucking up is not a corner case; in fact it's the norm.

tom9876543 wrote:
I agree with Brendan's statements. In an ideal world almost everything would be managed by a standardised PCI interface.

Except that Brendan did not actually say that: Brendan was suggesting a sane configuration mechanism via extensible ACPI-like tables. Brendan wanted to get rid of AML and not of any enumeration/configuration tables at all. And he didn't suggest that everything (processors, memory, whatever) should be on the PCI and be enumerated/configured via the PCI configuration mechanism.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sun Apr 02, 2017 6:03 am 
Offline
Member
Member

Joined: Wed Jul 18, 2007 5:51 am
Posts: 170
Korona wrote:
PCI should have absolutely nothing to do with CPU hotplug. There is no reason to pretend that CPUs or other devices are PCI devices when they are not. PCI is a bus and not a generic device discovery/configuration mechanism. It does not make sense from a technical point of view and it makes even less sense from a logical point.

OK Korona you appear to be the expert on CPU Hotplug. Please explain EXACTLY how CPU Hotplug is enabled.
I guess today it works something like:
1) Do a truck load of parsing of ACPI tables. Find the correct AML method.
2) Call a "CPU Hotplug Enable" AML enable method. Because AML is abstract, the processor has to parse the AML instructions and execute the instructions which are usually memory mapped io reads / writes. The memory mapped IO then enables the Hotplug. E.g. put value X into memory location Y.
I am more than happy for you to provide a more detailed accurate description.

Now here is my imaginary PCI bus version. The imaginary PCI bus version of CPU Hotplug is:
1) When enabling the PCI Host Bridge, read some bytes in configuration space and determine if CPU Hotplug is supported.
2) Put standard value X into standard location Y in the PCI Host Bridge configuration space to enable CPU Hotplug.

The imaginary PCI version is much more efficient. We don't have to waste a million CPU cycles parsing ACPI tables. There isn't the CPU overhead of converting AML into actual real CPU instructions. And there is ZERO bios involvement.

ACPI is a total failure for many reasons, 2 reasons:
it wastes millions of extra CPU cycles to get anything done
it relies on BIOS writers to provide bug free implementations


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Sun Apr 02, 2017 10:42 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Korona wrote:
Schol-R-LEA wrote:
Shall we start effusively praising ACPI now? 'Cos I would say that ACPI was made for this day.

:D I'm not a fan of ACPI at all; I'm just trying to point out that it's always easy to cry about things that you don't have to design yourself.


Never mind, I guess April Fools' Day is pretty much only a thing in English-speaking countries. I was just making an 'opposite day' joke, not responding to anyone in particular. The joke, which was as much about AFJs as it was about ACPI, was along the lines of, "Hey, it's April Fools, so we should started praising something we all despise, nudge nudge wink wink ironic posturing."

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


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Mon Apr 03, 2017 8:56 am 
Offline
Member
Member
User avatar

Joined: Wed Aug 17, 2016 4:55 am
Posts: 251
Brendan wrote:
Nonsense. Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with. We'd also be able to use some parts (e.g. fan control) without touching or caring about completely unrelated things (e.g. laptop battery levels), which is something that can't be done with ACPI (which is "all or nothing" - either you enable "ACPI mode" or you don't). This alone would make it significantly easier for small OSs, because you'd be able to add support for what you want when you want to (instead of having to deal with many MiB of bloat when the only thing you care about is power button state and nothing else).

As much as I'd like to agree, what's more likely to have happened is that everybody would have just been shipping drivers for Windows and be done with it (and then maybe other OSes if their users pester enough). This is not farfetched, just look what happened with GPUs, documentation is scarce or non-existent, we're lucky to barely even have the ability to set the video mode from BIOS/VESA/UEFI and that's it, not even DMA to load data from RAM into VRAM (which in itself would have been a huge improvement). And this is only because setting video modes is something firmware could do since forever (and VESA ensured we wouldn't be stuck with old video modes back when DOS still mattered), otherwise I'm not sure if we'd have even that today.

Mind you, I'd also love to force hardware manufacturers to have standarized on something (I will never attempt to make an OS on a PC because of how a massive mess it became), but I don't think that's ever going to happen on PC, not to mention manufacturer's obsession to keep as much under wraps as possible so they can get software vendors to pay for licenses instead. At this point we'd just need a clean state to start from (ditching backwards compatibility), and that probably means a whole new hardware platform altogether.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Mon Apr 03, 2017 12:17 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Sik wrote:
Brendan wrote:
Nonsense. Without AML, hardware manufacturers would have had to standardise the hardware, and we'd have a tiny number of simple devices (and some more information in static tables) to deal with. We'd also be able to use some parts (e.g. fan control) without touching or caring about completely unrelated things (e.g. laptop battery levels), which is something that can't be done with ACPI (which is "all or nothing" - either you enable "ACPI mode" or you don't). This alone would make it significantly easier for small OSs, because you'd be able to add support for what you want when you want to (instead of having to deal with many MiB of bloat when the only thing you care about is power button state and nothing else).

As much as I'd like to agree, what's more likely to have happened is that everybody would have just been shipping drivers for Windows and be done with it (and then maybe other OSes if their users pester enough). This is not farfetched, just look what happened with GPUs, documentation is scarce or non-existent, we're lucky to barely even have the ability to set the video mode from BIOS/VESA/UEFI and that's it, not even DMA to load data from RAM into VRAM (which in itself would have been a huge improvement). And this is only because setting video modes is something firmware could do since forever (and VESA ensured we wouldn't be stuck with old video modes back when DOS still mattered), otherwise I'm not sure if we'd have even that today.


Video cards and GPUs are "extremely high performance" and "extremely complex"; and things like frame rates and FLOP/s and VRAM bandwidth and fancy features are used for a competitive advantage. This means trade secrets and patents to protect that competitive advantage.

Things like IRQ routing, fan speed controllers, temperature sensors and power buttons are at the other extreme - they're simple, they're "low speed" and they're "mundane". There's no incentive to improve performance or research new "state of the art power button" features or to keep any of it a trade secret. There's no incentive to not follow a standard. Comparing it to video cards is insane.

More realistic would be comparing it to something like the "USB HID", where the devices are relatively simple (like power management hardware), and devices have no "high performance/speed" requirements (like power management hardware), and there's a variety of different devices involved (like power management hardware); and where manufacturers have stuck to a standard and where that standard has remained mostly unchanged for over 15 years.

Sik wrote:
Mind you, I'd also love to force hardware manufacturers to have standarized on something (I will never attempt to make an OS on a PC because of how a massive mess it became), but I don't think that's ever going to happen on PC, not to mention manufacturer's obsession to keep as much under wraps as possible so they can get software vendors to pay for licenses instead. At this point we'd just need a clean state to start from (ditching backwards compatibility), and that probably means a whole new hardware platform altogether.


As far as standardisation goes, everything else is worse than PC. Most don't even have "standardised firmware" or "standard device enumeration" (or anything else); and because of the lack of standards you have to port your OS to each different SoC; and because of the lack of standards it's impossible to have (e.g.) an "OS installer CD/flash image" for normal end users to download and install.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Why do we need the ACPI machine language?
PostPosted: Mon Apr 03, 2017 3:26 pm 
Offline
Member
Member
User avatar

Joined: Wed Aug 17, 2016 4:55 am
Posts: 251
Brendan wrote:
As far as standardisation goes, everything else is worse than PC. Most don't even have "standardised firmware" or "standard device enumeration" (or anything else); and because of the lack of standards you have to port your OS to each different SoC; and because of the lack of standards it's impossible to have (e.g.) an "OS installer CD/flash image" for normal end users to download and install.

Yeah I know (just look at phones, every one is its own unique thing), just saying that if you really wanted it, then you'd have to start a new platform with that specific goal in mind (potentially making and releasing your own specs instead of letting others touch it). Of course the chances of getting anybody on board with the idea are probably nil too... (at least unless you can put lots of marketing money to bring up the hype)

When it comes to existing ones then yeah screw that, PC is the only one even remotely close to any standard. At least some parts of it still remain more-or-less standarized.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Amazonbot [bot], Bing [Bot], DotBot [Bot], SemrushBot [Bot] and 55 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group