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.