uACPI, a portable and easy-to-integrate ACPI implementation

[8infy]

Not sure how to fix this. I've created a fork on github, but if I need to make too many modifications due to compiler problems, then it would be problematic to sync when uACPI is updated.

PRs are a thing, upstreaming compiler support is always welcome as long as it doesn't break existing code.

[marv7000]

Portable code should not rely on new C features, particularly not when they can be avoided without much impact.

To be completely honest, "portable code" does not mean it has to rot on a decade old C standard. You should probably just switch to a competent compiler...

[rdos]

Portable code should not rely on new C features, particularly not when they can be avoided without much impact.

To be completely honest, "portable code" does not mean it has to rot on a decade old C standard. You should probably just switch to a competent compiler...

There is no competent (or not) compiler that supports the 32-bit compact memory model other than Open Watcom, so this is simply not a solution. I might use uACPI as a service, running in a flat memory model, but the problem then is that all APIs are register based, and GCC use some very ancient standard for both inline assembly and defining register calling conventions. And even if I migrated those, it is not possible to create a decent libc for GCC that can be integrated into the project. Newlib is not good enough either since its multithreading interface is horrible. RDOS is very well integrated into Watcom, both for device drivers and applications.

[eekee]

4. Binary encodings (e.g. 0b11) are not standard C and are not supported by watcom.

And that's a C23 feature. A pretty useless one as long as hex constants still exist. I do not get why people are so enamored with writing long strings of zeroes and ones.

It's easily implemented and useful for the more easily confused kind of programmer such as myself. Whether that's a good thing overall, I leave as a question for the ages. I've grown tired of defending my corner.

[thewrongchristian]

4. Binary encodings (e.g. 0b11) are not standard C and are not supported by watcom.

And that's a C23 feature. A pretty useless one as long as hex constants still exist. I do not get why people are so enamored with writing long strings of zeroes and ones.

It's easily implemented and useful for the more easily confused kind of programmer such as myself. Whether that's a good thing overall, I leave as a question for the ages. I've grown tired of defending my corner.

I think it is an easily defended corner.

Some data simply encode bits, and it seems perfectly reasonable to define that data in terms of the data it's representing. Ie. binary data constants.

That you can represent such data in hex, decimal or octal is neither here nor there, and it is intellectual snobbery to look down on the idea of representing binary data as such in source code.

[nullplan]

Some data simply encode bits, and it seems perfectly reasonable to define that data in terms of the data it's representing. Ie. binary data constants.

I do not understand that part. No data can encode bits, rather, bits encode data. But my point is another one.

That you can represent such data in hex, decimal or octal is neither here nor there, and it is intellectual snobbery to look down on the idea of representing binary data as such in source code.

I have seen one too many 64-bit binary literals to even entertain the idea of binary literals. For small numbers, it is probably fine, although then the effort to convert it from hex is not too great, but long strings of bits are simply overwhelming me. And hexadecimal has the advantage of both simply being an abbreviation of binary (4 bits per digit) and lining up with byte boundaries. This compresses the information to a useful length and more easily allows the reader to understand the code. And fundamentally, readability matters a lot more than writability. See Perl for a refresher on that particular lesson.

For example, you can write a GDT descriptor as

Code: Select all

0b0000000011001111100110100000000000000000000000001111111111111111

but if you write it as

Code: Select all

0x00cf9a000000ffff

you will see the important parts more quickly. In the alternative, you can clutter the whole thing with macros, but I don't think this would make it a whole lot better. The macros would only make sense to people that have the documentation open anyway, and they will know the exact same thing from the hex.

[thewrongchristian]

Some data simply encode bits, and it seems perfectly reasonable to define that data in terms of the data it's representing. Ie. binary data constants.

I do not understand that part. No data can encode bits, rather, bits encode data. But my point is another one.

That you can represent such data in hex, decimal or octal is neither here nor there, and it is intellectual snobbery to look down on the idea of representing binary data as such in source code.

I have seen one too many 64-bit binary literals to even entertain the idea of binary literals. For small numbers, it is probably fine, although then the effort to convert it from hex is not too great, but long strings of bits are simply overwhelming me. And hexadecimal has the advantage of both simply being an abbreviation of binary (4 bits per digit) and lining up with byte boundaries. This compresses the information to a useful length and more easily allows the reader to understand the code. And fundamentally, readability matters a lot more than writability. See Perl for a refresher on that particular lesson.

For example, you can write a GDT descriptor as

Code: Select all

0b0000000011001111100110100000000000000000000000001111111111111111

I think an example that might be more reasonable is data to define some built in bitmap font, you can define the bit patterns in binary constants like:

Code: Select all

uint8_t bitmap[] = {
	0b00000000,
	0b00111100,
	0b01000010,
	0b01000010,
	0b01111110,
	0b01000010,
	0b01000010,
	0b00000000,
};

It is much more clear what this data is representing when defined using binary constants.

[rdos]

I think it's very useful in Verilog where you often work with buses and bits rather than bytes. With bytes, it only have questionable value.

[eekee]

I have seen one too many 64-bit binary literals to even entertain the idea of binary literals. For small numbers, it is probably fine, although then the effort to convert it from hex is not too great, but long strings of bits are simply overwhelming me. And hexadecimal has the advantage of both simply being an abbreviation of binary (4 bits per digit) and lining up with byte boundaries. This compresses the information to a useful length and more easily allows the reader to understand the code. And fundamentally, readability matters a lot more than writability. See Perl for a refresher on that particular lesson.

I've recently had a lesson in readbility from Forth, it's very fresh in my mind. Using hex for bitfields is not very readable for me. Perhaps it would be with practice, but after all these years of interest in low-level coding and digital electronics, I'm still not fluent; I don't immediately think of the bit pattern for every digit. I do for some, but not others.

However, this is an abomination!

Code: Select all

0b0000000011001111100110100000000000000000000000001111111111111111

Whatever the base, long numbers should never be written without separators. (The underscore makes a good separator, especially when allowed at arbitrary positions.) I dislike 32-bit hex without at least 1 separator, never mind binary of any length. I dislike compilers which don't accept separators, but comments can obviate the need for separators, especially in bitfields. Compile-time expressions are better still, and I really don't like languages which don't allow them. The above GDT example could be:

Code: Select all

//  gdl-         pDPsedwa         limit_________  base=0
  0b1100<<52 | 0b10011010<<40 | 0xf<<48 | 0xffff

In the absence of compile-time expressions, I think separators help a lot. Without a comment, double underscores separate sections:

Code: Select all

  0b0000_0000__1_1_0_0__1111__1_00_1_1_0_1_0__0000_0000_0000_0000_0000_0000__1111_1111_1111_1111

With a comment, there's all sorts of ways to arrange it.

Code: Select all

//  basehi___ gdl- limithi pDPsedwa baselo_______________________ limitlo____________
  0b0000_0000_1100_1111____10011010_0000_0000_0000_0000_0000_0000_1111_1111_1111_1111

//  basehi     g d l -  limithi  p dp s e d w a  baselo                         limitlo
  0b0000_0000__1_1_0_0__1111_____1_00_1_1_0_1_0__0000_0000_0000_0000_0000_0000__1111_1111_1111_1111

[nullplan]

Whatever the base, long numbers should never be written without separators.

Then you will be pleased to hear that with C23, the single quote (') can be used as separator in the middle of any digit string. You can place them wherever you should want.

[rdos]

uACPI now has OpenWatcom support, but the code must be compiled with a special C99 switch. This is a bit problematic when integrating it into other projects, so I've made a fork that builds with standard Watcom switches. I plan to add my RDOS server to this fork too.

[rdos]

The ACPI tables appear to load correctly on at least one computer now (but it logs a few bugs in the tables).

I wonder a bit about why mutexes have timeouts (this is not supported in my futex-based implementation). AFAIK, there is no timeout explicitly passed to the request method, so I'm ignoring the timeout flag for now.

I also wonder a bit about IO ports. It's nice that the mapping function has a base & size, but I still wonder if this means I can use the IO permission bitmap in the TSS to selectively enable & disable access to IO ports? This would work if no overlapping IO maps are created, but if there is such a possibility, then there would be a need for reference counting.