OSDev.org

Hi guys,
I know the wiki is free for editing, but I just want to check if I am right before I make any edits (Especially since I am not so good at inline assembly). Regarding the INx function, am I right to say there are some issues with the code? Should the line

be replaced with

Thanks.

I'd probably drop the "symbolic operand name" example instead; the very error itself is a good example as to why you should avoid introducing identifiers when you don't have to.



Then again, I am by no means an expert on the inline assembly syntax, have never actually used it myself, and have no idea if the code above does what it should or will launch da bomb.

Hm...I guess since there is only two operands anyway, it should be still fine to not use the symbolic names and use them in any order.
Though I feel having symbolic names feel more natural, but its probably personal preference.
And I am sure that code can't mess up that badly if it is wrong. Unless the OS happens to use this function and for some reason is used to control a nuclear reactor. I guess that will really drop the bomb.

It is.

I've spent the last 15 years doing maintenance on other people's code. Every identifier removed from the code in favor of directly using a temporary means one thing less to keep track of, mentally; and with C++11, having a value being an unnamed temporary means move semantics, further boosting my personal preference.

YMMV.

I think that a lot of programmers - especially early in their careers - often take the general defensive programming advice 'avoid hard-coded constants with arbitrary or otherwise non-obvious meanings, especially if they may change in the future' as meaning 'always use a new symbolic name for every new value'. This can color ones view in several areas, including this sort of anonymous temporaries. As with the usual advice of avoiding gotos in HLLs, it takes some time to learn the nuances of where to relax that discipline, where following the heuristic makes things worse rather than better, etc.

Also, that advice, while generally applicable, doesn't fit this context very well; another heuristic is that inline assembly should not exceed 5-7 lines without an overriding reason, which means that unless the context is an unusual one, there is little information lost from using anon temporaries in inline assembly, while using the named variables from one local namespace in a completely independent namespace can lead to exactly this sort of collision.