Re: uACPI, a portable and easy-to-integrate ACPI implementation
Posted: Fri May 09, 2025 3:26 pm
PRs are a thing, upstreaming compiler support is always welcome as long as it doesn't break existing code.
The Place to Start for Operating System Developers
http://f.osdev.org/
PRs are a thing, upstreaming compiler support is always welcome as long as it doesn't break existing code.
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.
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.eekee wrote: ↑Sat May 10, 2025 5:04 amIt'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 do not understand that part. No data can encode bits, rather, bits encode data. But my point is another one.thewrongchristian wrote: ↑Sat May 10, 2025 5:36 am 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 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.thewrongchristian wrote: ↑Sat May 10, 2025 5:36 am 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.
Code: Select all
0b0000000011001111100110100000000000000000000000001111111111111111Code: Select all
0x00cf9a000000ffffI 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:nullplan wrote: ↑Sat May 10, 2025 10:44 amI do not understand that part. No data can encode bits, rather, bits encode data. But my point is another one.thewrongchristian wrote: ↑Sat May 10, 2025 5:36 am 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 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.thewrongchristian wrote: ↑Sat May 10, 2025 5:36 am 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.
For example, you can write a GDT descriptor asCode: Select all
0b0000000011001111100110100000000000000000000000001111111111111111
Code: Select all
uint8_t bitmap[] = {
0b00000000,
0b00111100,
0b01000010,
0b01000010,
0b01111110,
0b01000010,
0b01000010,
0b00000000,
};