Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please restore our registers when you’re done with them

randomascii.wordpress.com

Post reply on HN
Print view View original

41–50 of 142 posts

Re: Please restore our registers when you’re done with them

#41

Post by ElevenLathe »

masklinn wrote: post #27
Joker_vD wrote: post #25

Earlier quoted context omitted.

Doesn't GCC inline assembly actually track that info, with the "clobber" section?

Yes, but it's not a property of the assembly (or assembler), it's a necessity for the compiler to correctly codegen around the inline assembly. Historically, assemblers have been really dumb, so ABI is not a thing they'd track, especially as... I don't think they know what functions are? So while they can notice call/ret, they have no knowledge of a label being a jump or call target per-se, do they? So you'd need an…

I mean if you have a macro assembler you should be able to write a macro that generates "save registers" instructions before a section of code and "restore registers" instructions after it. The assembler doesn't need to know our care that this section of code is a function.

It's interesting how blurry the line is between a good, full-featured assembler and a crappy compiler!

Re: Please restore our registers when you’re done with them

#42

Post by otikik »

Naïve question about ABIs: shouldn’t the caller be responsible for that? If I want a function to restore certain registers, wouldn’t it be simpler if I was the one that save them on my memory, call the function, and then override the registers with whatever values the function set? Otherwise it seems we’re just… asking for trouble, so to speak.

Re: Please restore our registers when you’re done with them

#43

Post by dannymi »

otikik wrote: post #42

Naïve question about ABIs: shouldn’t the caller be responsible for that? If I want a function to restore certain registers, wouldn’t it be simpler if I was the one that save them on my memory, call the function, and then override the registers with whatever values the function set? Otherwise it seems we’re just… asking for trouble, so to speak.

It would just be slow for the caller to have to push and pop (say 30) registers in general that the specific callee (and transitive callees) may not even use.

Most ABI specify some registers caller-saved, some registers callee-saved (retained unchanged from the perspective of the caller) and some registers scratch (not-saved).

In the end it depends on the architecture and on typical workload which are the fastest--and measurements can be made and it can be found out which combination is the fastest on average.

Re: Please restore our registers when you’re done with them

#44

Post by masklinn »

ElevenLathe wrote: post #41
masklinn wrote: post #27

Earlier quoted context omitted.

Yes, but it's not a property of the assembly (or assembler), it's a necessity for the compiler to correctly codegen around the inline assembly. Historically, assemblers have been really dumb, so ABI is not a thing they'd track, especially as... I don't think they know what functions are? So while they can notice call/ret, they have no knowledge of a label being a jump or call target per-se, do they? So you'd need an…

I mean if you have a macro assembler you should be able to write a macro that generates "save registers" instructions before a section of code and "restore registers" instructions after it. The assembler doesn't need to know our care that this section of code is a function. It's interesting how blurry the line is between a good, full-featured assembler and a crappy compiler!

> I mean if you have a macro assembler you should be able to write a macro that generates "save registers" instructions before a section of code and "restore registers" instructions after it.

Except you want a "macro" which:

- saves only the registers you touched

- which are callee-saved

- according to the ABI you're targeting

And you really only want that for functions, because... that's where ABIs come into play.

Re: Please restore our registers when you’re done with them

#45

Post by chrisseaton »

otikik wrote: post #42

Naïve question about ABIs: shouldn’t the caller be responsible for that? If I want a function to restore certain registers, wouldn’t it be simpler if I was the one that save them on my memory, call the function, and then override the registers with whatever values the function set? Otherwise it seems we’re just… asking for trouble, so to speak.

> If I want a function to restore certain registers, wouldn’t it be simpler if I was the one that save them on my memory, call the function, and then override the registers with whatever values the function set?

That's a waste if the callee doesn't use them.

Re: Please restore our registers when you’re done with them

#46

Post by titzer »

gumby wrote: post #13
bombcar wrote: post #12

Earlier quoted context omitted.

It seems to me something that could be found by some kind of valgrind-like tool - it'd be much slower than normal code but "ABI exception detected" or something.

Not worth checking for. The few people who write assembly code these days know what they are doing, and, bugs aside, the compiler knows what to do.

The old Russian proverb is "Trust but verify."

I, for one, hate debugging asm. I do it a lot, and would prefer bugs be caught automatically, preferably soon after they are introduced.

Re: Please restore our registers when you’re done with them

#47

Post by denton-scratch »

masklinn wrote: post #27
Joker_vD wrote: post #25

Earlier quoted context omitted.

Doesn't GCC inline assembly actually track that info, with the "clobber" section?

Yes, but it's not a property of the assembly (or assembler), it's a necessity for the compiler to correctly codegen around the inline assembly. Historically, assemblers have been really dumb, so ABI is not a thing they'd track, especially as... I don't think they know what functions are? So while they can notice call/ret, they have no knowledge of a label being a jump or call target per-se, do they? So you'd need an…

> I don't think they know what functions are?

It's a long time since I tangled with x86 assembler; but as I recall, ENTER and LEAVE were specifically for functions, and I'm not aware of any other use for them.

Re: Please restore our registers when you’re done with them

#48

Post by von_lohengramm »

I'm sure some C++ lawyer can correct me, but isn't branching off of `m_ptr` (e.g. `CHECK()`ing the value) after `std::move(m_ptr)` technically Unspecified Behavior since `std::move(m_ptr)` leaves `m_ptr` as an Unspecified Value? It would be up to the compiler to define the behavior if they so pleased, but the C++ spec would not require such behavior to be defined at all.

Re: Please restore our registers when you’re done with them

#49

Post by tux3 »

von_lohengramm wrote: post #48

I'm sure some C++ lawyer can correct me, but isn't branching off of `m_ptr` (e.g. `CHECK()`ing the value) after `std::move(m_ptr)` technically Unspecified Behavior since `std::move(m_ptr)` leaves `m_ptr` as an Unspecified Value? It would be up to the compiler to define the behavior if they so pleased, but the C++ spec would not require such behavior to be defined at all.

Moves in C++ don't make the whole object invalid, it just leaves them in a valid but unspecified state, so that at least the destructor can still run.

This means calling operator bool on your unique_ptr ought to be fine, because the unique_ptr still has a valid state (you don't know what that state is, it's unspecified, but it's guaranteed to not be radioactive on mere contact. It has to be a valid unspecified state.)

Re: Please restore our registers when you’re done with them

#50

Post by twoodfin »

von_lohengramm wrote: post #48

I'm sure some C++ lawyer can correct me, but isn't branching off of `m_ptr` (e.g. `CHECK()`ing the value) after `std::move(m_ptr)` technically Unspecified Behavior since `std::move(m_ptr)` leaves `m_ptr` as an Unspecified Value? It would be up to the compiler to define the behavior if they so pleased, but the C++ spec would not require such behavior to be defined at all.

It’s an unspecified but required to be valid value for the moved type. The author mentions it’s a smart pointer type, which could easily be defined to act like this.
Post reply on HN