Hi,
I've written an article about the optimizations used in SoftWire, my open-source x86 code generator: http://sw-shader.sourceforge.net/optimization.html . Any comments about the article would be much appreciated. Especially if you have difficulties understanding certain parts, or have suggestions how to improve it.
Thanks!
I've written an article about the optimizations used in SoftWire, my open-source x86 code generator: http://sw-shader.sourceforge.net/optimization.html . Any comments about the article would be much appreciated. Especially if you have difficulties understanding certain parts, or have suggestions how to improve it.
Thanks!
hi nick,
your link is bad, you'll need to remove the period from it.
Thanks,
_Shawn
your link is bad, you'll need to remove the period from it.
Thanks,
_Shawn
Thanks for notifying me!
Hello C0D1F1ED
A marvelous article! The explanations were both interesting and precise, and I especially liked the Load Elimination section, as it provided a simple explanation for a principle that makes understanding the following sections easier.
I have some little remarks, and a question.
The calling order is unspecified by the C++ standard.
Constructors and destructors are not operators. They are special member functions.
The question is: How do you treat instruction mnemonics that clash with C++ keywords and alternative tokens?
I assume 'int' doesn't pose much of a problem, since it's not used much in algorithms and application code. What about 'and', 'or', 'not' and 'xor'? The standard defines these as alternative representations for certain operators, and treating them differently yields an ill-formed program.
A marvelous article! The explanations were both interesting and precise, and I especially liked the Load Elimination section, as it provided a simple explanation for a principle that makes understanding the following sections easier.
I have some little remarks, and a question.
The right r32() gets called first, then the left one, and then the run-time intrinsic.
The calling order is unspecified by the C++ standard.
Two more C++ operators had to be implemented to make this work. First of a copy constructor was needed. The implementation is very simple, using a mov run-time intrinsic just like emitAssign() . The other operator is the destructor.
Constructors and destructors are not operators. They are special member functions.
The question is: How do you treat instruction mnemonics that clash with C++ keywords and alternative tokens?
I assume 'int' doesn't pose much of a problem, since it's not used much in algorithms and application code. What about 'and', 'or', 'not' and 'xor'? The standard defines these as alternative representations for certain operators, and treating them differently yields an ill-formed program.
A marvelous article! The explanations were both interesting and precise, and I especially liked the Load Elimination section, as it provided a simple explanation for a principle that makes understanding the following sections easier.
Thanks! Much appreciated.
The calling order is unspecified by the C++ standard.
Ah, I didn't know this. I just determined it experimentally and thought it was the standard. Either way it's not in any way critical, it was just to explain how C++ calls the functions sequentially and this generates exactly the code we want.
Constructors and destructors are not operators. They are special member functions.
That's true, thanks for notifying this. I'll look for an alternative way to write what I'm trying to say...
The question is: How do you treat instruction mnemonics that clash with C++ keywords and alternative tokens?
I assume 'int' doesn't pose much of a problem, since it's not used much in algorithms and application code. What about 'and', 'or', 'not' and 'xor'? The standard defines these as alternative representations for certain operators, and treating them differently yields an ill-formed program.
I assume 'int' doesn't pose much of a problem, since it's not used much in algorithms and application code. What about 'and', 'or', 'not' and 'xor'? The standard defines these as alternative representations for certain operators, and treating them differently yields an ill-formed program.
Frankly, treating these words as keywords is C++-rapism in my opinion. It's a programming language, not a poetry contest. It serves no purpose whatsoever to define them. Luckily Visual C++ disables them by default. I'm quite sure they caused more trouble at their introduction then they solved. It doesn't seem unlikely that these names have been used a lot as variable names in the past.
When I first found out SoftWire doesn't compile on GCC because of this, I asked the same question on several forums. The general answer was that these keywords have been added for no important reason and slipped through the qualification process.