Namespaced variables should not be tolerared in assembler code

[GoogleCodeExporter]

I was right about r435 -- c++ is not clever decision to play with assembler
code. c++ + assembler == c-style code, no c++ templates, function overload
and namespaces in parts connected with assembler allowed. 

For example, in x86/aR3900A.S there is variable psxRecLUT. Oh, nice
variable, but it declared only in Dunarec namespace, so it SHOULD NOT be
applicable in assembler code, as assembler use only general namespaced
names! Linker should break here, but VS is very loyal to programmer and
even linked this name to proper variable. But! If you made another
namespace with the same variable linker would probably (50/50, depends on
file structure) link it to this second one and you'v got unfindable segfaults.

I must insist that all assembler code DICTATE plain c-style coding
standards, you could think as assembler is some sort of old C. 

So I think all variables, that appeared in assembler code should be remove
from namespaces. And I suggest not to use namespaces at all to avoid future
misforurenes.

Original issue reported on code.google.com by Zeydl...@gmail.com on 16 Jan 2009 at 12:32

[GoogleCodeExporter]

Visual Studio does not use any .S files except for VifDma-related assembler 
stuff,
which is all declated external and is un-namespaced.  Thus:

* Yes having namespaces breaks external .S assembly code.
* No, VS does not make "nice" assumptions, it just has a "nice" inline asm 
feature
that we can use and understand, thus we use inline asm for almost everything in 
MSVC.
* Yes, inline asm in VS correctly resolves namespaces.
* No, the namespace system isn't ideal yet either.  I'll remove the dynarec 
namespace
soon and replace it with a smarter design now that I've been able to isolate 
many of
the inter-dependencies.
* Yes, converting the external .S files to inline Linux ASM would also fix 
linux such
that it could resolve namespaced names.

Namespaces improve name safety, not reduce them.  Crazy false excuses to the 
contrary
won't make it any less a reality.

Original comment by Jake.Stine on 16 Jan 2009 at 4:36

• Changed state: Invalid