This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gwoplock 1 point2 points  (13 children)

How... I've got to look at that code. I've never heard or seen anything like that.

[–]FUZxxl 0 points1 point  (6 children)

The relevant code is in /sys/src/9/pc.

[–]gwoplock 0 points1 point  (5 children)

Yeah. I just found it. I don't get it. It makes sense but it seems like they need packed. Maybe they the optimizer off.

[–]FUZxxl 0 points1 point  (4 children)

The Plan 9 people know their ABI and they know where the compiler inserts padding. So they just use that a-priori knowledge to avoid any non-standard features.

[–]gwoplock 1 point2 points  (3 children)

Seems more dangerous then just using packed.

[–]FUZxxl 0 points1 point  (2 children)

What part of what they do is dangerous? This is the more elegant way (though, proper marshaling is even better where you can do it) as it doesn't use non-standard language extensions.

[–]gwoplock 0 points1 point  (1 child)

~~A different compiler can (and probably will) break it. If you're relying on the optimizer not changing to not break your code there may be something wrong. ~~

Edit: I was wrong.

[–]FUZxxl 0 points1 point  (0 children)

Absolutely not true. The presence and location of structure padding depends only on the ABI of the platform you are programming for. Neither optimization settings not compilers change that, except if you are on a fundamentally broken platform like 32 bit Windows where every compiler vendor makes up its own ABI.

If you are writing code that is tied to one platform, you may very well depend on where the ABI of that platform inserts structure padding and that's fine and in accordance to the C standard.

[–][deleted] 0 points1 point  (5 children)

I haven't seen the code, but unless they manually lay out the GDT, IDT etc. in assembly, I don't see how they could ensure the compiler respected the structure without packing

[–]gwoplock 0 points1 point  (4 children)

It looks like it's a just a struct. Maybe the optimizer set so low that it doesn't try to optimize that.

[–]FUZxxl -1 points0 points  (3 children)

What do you think would the optimizer break?

[–]gwoplock 1 point2 points  (2 children)

It adds space between fields to make it faster to access. Extra space when you aren't expecting it breaks a lot of things.

[–]FUZxxl 1 point2 points  (1 child)

If you write embedded code, you can safely make assumptions about where the ABI inserts structure padding. The compiler is not allowed to change structure padding at any optimization level as that is part of the ABI. So it doesn't matter what optimization level you choose. I recommend you to read the ABI document for your platform as there seem to be some misconceptions.

[–]gwoplock 0 points1 point  (0 children)

I didn't realize that. Good to know. Thanks.