OSDev.org

Posted: **Fri May 09, 2025 3:26 pm**

rdos wrote: ↑Fri May 09, 2025 7:59 am 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.

Posted: **Fri May 09, 2025 5:39 pm**

rdos wrote: ↑Fri May 09, 2025 11:29 am 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...

Posted: **Sat May 10, 2025 5:00 am**

marv7000 wrote: ↑Fri May 09, 2025 5:39 pm
rdos wrote: ↑Fri May 09, 2025 11:29 am 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.

Posted: **Sat May 10, 2025 5:04 am**

nullplan wrote: ↑Fri May 09, 2025 8:55 am
rdos wrote: ↑Fri May 09, 2025 7:59 am 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.

Posted: **Sat May 10, 2025 5:36 am**

eekee wrote: ↑Sat May 10, 2025 5:04 am
nullplan wrote: ↑Fri May 09, 2025 8:55 am
rdos wrote: ↑Fri May 09, 2025 7:59 am 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.

Posted: **Sat May 10, 2025 10:44 am**

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

Posted: **Sun May 11, 2025 5:16 am**

nullplan wrote: ↑Sat May 10, 2025 10:44 am
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 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 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.

Posted: **Sun May 11, 2025 11:00 am**

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.

Posted: **Mon May 12, 2025 2:08 pm**

nullplan wrote: ↑Sat May 10, 2025 10:44 am 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

Posted: **Tue May 13, 2025 9:20 pm**

eekee wrote: ↑Mon May 12, 2025 2:08 pm 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.

Posted: **Wed May 14, 2025 3:37 am**

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.

Posted: **Fri May 16, 2025 8:54 am**

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.

Posted: **Sun May 18, 2025 4:48 am**

uACPI now supports OpenWatcom natively even in C89 mode thanks to the work done by monkuous over the last few weeks. We even have it running on CI and passing all uACPI tests on both Windows and Linux.

Posted: **Sun May 18, 2025 6:07 am**

rdos wrote: ↑Fri May 16, 2025 8:54 am 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.

I just use IOPL for the time being, but it does indeed look like you would have to do refcounting if you want to have proper protections and stuff. I was also thinking about switching to the IO bitmap mechanism for drivers in my kernel, but I have too many things on my TODO list and haven't given it much thought yet.

Posted: **Sun May 18, 2025 10:38 am**

mishakov wrote: ↑Sun May 18, 2025 6:07 am
rdos wrote: ↑Fri May 16, 2025 8:54 am 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.
I just use IOPL for the time being, but it does indeed look like you would have to do refcounting if you want to have proper protections and stuff. I was also thinking about switching to the IO bitmap mechanism for drivers in my kernel, but I have too many things on my TODO list and haven't given it much thought yet.

I discovered that my IO bitmap only covered the first 0x400 ports, and most modern ports are higher than that, so I had to let those go to the kernel, since when ports outside the IO bitmap are accessed, this causes a protection fault. I might want to try to build a full IO permission bitmap for the main thread in the uACPI server.

I think a possible method might be that if any of the bits in the IO permission bitmap are already active, then I send back a flag not to disable the port on free to the server. Thus, if a port is accessed in many requests, then it will remain active after all the requests are closed, while normal requests result in disabled ports as they should.

Semaphores should really not be necessary in my implementation since I will let only a single thread call the uACPI library.

OSDev.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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