AFAIK it's a standard test for C and C++ compilers to compile themselves...
Printable View
AFAIK it's a standard test for C and C++ compilers to compile themselves...
Thanks a lot, James!
Actually, I've always been darn curious about how compilers were created in the first place.
In the programming world, compilers are like God.
God created stuff in the universe, but who created God? That's the same with compilers.
U use C/ASM to create the very first version of Visual C++. But how do u create the C compiler in the first place? Probably with an ASM compiler. But what do they use to create the ASM compiler? With ML compilers, I think. And what do they use to create the ML compilers? Bare hands, probably. And what do they use to create the bare hands? The ancestors of humans passed them down, probably. And who created the human ancestors?.......(topic has changed from compiler discussion to evolution of species:D:D)
Here is what Bjarne Stroustrup answers to the question "Which language did you use to write C++?" . If the link does not jump to the label, look for the question by yourself in the page.
Oh I see!
Thanks a lot, Gabriel! :):D
CL.EXE is the compiler, not the IDE. MSDEV.EXE (and a heck of a lot of *.dll's) are the IDE. Although I still fail to see why the compiler in this day and age has to be commandline.
Figuring how MS thinks of things, I thought they'd make the compiler part a COM object (God forbid!). When they do that - the IDE is will be either a C#/VB.NET app completely. And further pushing down C++ in MS's eyes. (Okay, I guess I don't see it as that bad of a thing - considering I'm getting a dual boot machine soon that boots Linux and Windows 2000) - I don't feel like someday NEEDING 512 MB of RAM to run a compiler with it's IDE. (Visual Studio.NET as is REQUIRES 128 MB of RAM. I have 256 MB of RAM right now, Win98 takes up 32 MB of that, and add on my firewall, etc... that run all the time - and if I ran that app - I'd be in virtual memory for sure. And people wonder why I optimize the h*ll out of my own *.exe's and *.dll's for size - (exporting by ordinal instead of name, using #pragma comment(linker,"OPT:/NOWIN98"), run only a few threads at a time instead of like 50 - (yes, I've seen app's run 50 threads at one time, all with the default stack space of 1MB even though every one of those threads does not need 1MB, etc... - the only application that has any use for running that many threads is a server of some sort, that has many concurrent connections.))
Right except for one thing - I don't think that there is a such thing as a ML compiler - considering machine code is the actual binary data interpreted by the machine. Applications coded in ML are hand coded all the way. (I can see how a linker could be useful for this purpose - coding object files in ML (hand coding) and linking via the linker). And the correct term for an ASM compiler, is just an assembler - it's technically not a *compiler*, as a compiler turns text code (such as C++) to assembly code, which assembly instructions have a one-to-one mapping with a machine code operand (yes, I know this probably isn't the right term - but logically, you get what I mean.) - in assembly, the instruction maps to machine code, if you use a register (and what register) and/or a memory location changes the output of the code as well.Quote:
Originally posted by Xeon
Thanks a lot, James!
Actually, I've always been darn curious about how compilers were created in the first place.
In the programming world, compilers are like God.
God created stuff in the universe, but who created God? That's the same with compilers.
U use C/ASM to create the very first version of Visual C++. But how do u create the C compiler in the first place? Probably with an ASM compiler. But what do they use to create the ASM compiler? With ML compilers, I think. And what do they use to create the ML compilers? Bare hands, probably. And what do they use to create the bare hands? The ancestors of humans passed them down, probably. And who created the human ancestors?.......(topic has changed from compiler discussion to evolution of species:D:D)
When you write an assembler - you learn what the maker of the chip defines as it's assembly instructions, and what they want you define to map to this specific binary output.
But on the other hand, you could argue that it is a compiler - in the fact that you still parse 'text' code, albeit assembly.
The computer doesn't understand 'assembly' instructions - all it understands is 1's and 0's, whether power is 'on' or 'off' at that particular location. The 'bit depth' of the processor, 32 bit for example - is the amount that a processor 'reads' to read/write/execute at one time (generically speaking).
In generic terms - back to assembly mapping to machine code - it is much easier to think of 'moving' some data to another location by the 'mov' instruction instead of looking up the actual binary output to accomplish this task. That is the idea behind assembly.
For example, say you have a memory location that is 32 bits long, and stores the value 0xFFFFFFFF in hexadecimal (all bits set in binary) - and you want to move it to another location. In C++, like this...
Now, UNOPTIMIZED, the assembly code to do this would be something like this: - keep in mind I use the name of C++ variable, as it would be used in inline assembly of the compiler.Code:unsigned long dwOriginalLocation(0xFFFFFFFF); // When I initialize variables
// at declaration - I use this method defined by C++ instead
// of =
unsigned long dwNewLocation = dwOriginalLocation;
And the assembler would map it to the correct ML output.Code:mov eax,dwOriginalLocation ; just say that dwOriginalLocation
; has existed for awhile
mov dwNewLocation,eax
Some compilers have the option to show you the assembly output (and in comment, it's corresponding machine code in text form) - you can do this with VC++ (atleast 6.0) - go to the listing files section of the compiler options. (I do it for getting the mangled names of C++ functions after my large *.dll projects reach around 700+ exports, so I can't just temporarily use __declspec(dllexport) and Dependency walker to get the names. - plus, you can only get new and delete operators mangled name by doing this as __declspec(dllexport) does not work on them. (Maybe a *.map file can??? - never used it)) - maybe C++ should have an extension added to it - like a keyword, such as 'mangled_name(function_declaration)' and the compiler should replace it with a constant string with the mangled name? And have a corresponding 'unmangle_name(const char * pstrMangled) which could be a function. I already asked one person who was knowledgable in C++ (supposedly) and he said the language shouldn't bend towards how the outer internals of an OS or specific implementation does things. (Then why oh why has __declspec(dllexport) become pretty standard across environments? The need to export from shared libraries?) I can see more use of out knowing the mangled name of a C++ function than I do of type info, but type info is there in the language. Sure, using typeid, you can get the function TYPE (like this)
But that's a COMPILE time check, run that code and you'll get:Code:void MyFunction() throw();
//...
std::cout << typeid(MyFunction).name() << std::endl;
void (__cdecl*)(void) on VC++ - but you know that since you wrote the function - raw_name() returns whatever the compiler decides to represent this type. What you DON'T know at compile time, is the mangled name - however - the compiler DOES know this - so it makes even more sense to put that in.
Ah, I think this is definitely my last post in this thread - because I seem to take one point to another, and eventually totally go off topic. (More discussion? Start another thread)
God! James! Have you thought of writing a book on the relationship between ASM and C++, the links between 'em and such? WHOA!!!!!!! :eek::eek::eek::eek::eek::eek:
Actually - I will eventually write a C++ compiler (you've no doubt seen my plans for the future :p in other posts of mine) - normally, I don't comment my code very much, unless it's a complicated section (just so I can remember what I did some years later) - but when I do - I'll comment the source very heavy - although, I tend to write LOGICAL code (what I mean by logical, is naming things well, and well thought out classes - opposed to all the dirty 'C' and macro code you see with alot of compression libraries), and keep the SPEED portions to inline functions that need little explanation (if it needs to be fast, I live and die by the method - if it's called in a loop - it should be inline). Is that close enough to a book explaining the relationships between all this?Quote:
Originally posted by Xeon
God! James! Have you thought of writing a book on the relationship between ASM and C++, the links between 'em and such? WHOA!!!!!!! :eek::eek::eek::eek::eek::eek:
A book is still the best, but aye~! I guess u're a full true blue compiler guy more than a programmer. :):DQuote:
). Is that close enough to a book explaining the relationships between all this?
But anyway, in order not to tempt you to make another post in this thread again, I'll shut up.:):):)
Why not just invent a new language -- easy to use like VB (or other Basics) -- yet powerful enough like C?Quote:
Originally posted by JamesSchumacher
Actually - I will eventually write a C++ compiler . . .
Maybe that's something I could do - I don't plan on doing it for about 10 years (allow me to get farther along in life, marriage, kids, etc... and expand my programming knowledge even further). 10 years down the road, it might be a very viable solution.Quote:
Originally posted by aio
Why not just invent a new language -- easy to use like VB (or other Basics) -- yet powerful enough like C?
If I could predict the future - let me play a devil's advocate here - what I'd probably do, is do something similar to how GCC does things - allow things to be syntax different, allowing 'plugin' modules to expand it's language recognization - but require certain things of the language - like true OOP support (everything C++ has, all forms of inheritance, virtual functions, etc...) just so all the languages would be binary compatible. Basically - do what Microshaft is trying to do with COM objects and JIT crap - except do it at the lowest level instead of the overhead all that stuff brings.
I think one thing I would do, is at the top of the include files and source files, require something like assembly has with:
Which means to target 386 compatible machines, with something like:Code:.386
So mixed language source files could be used in a project.Code:Compiler.Language = __cplusplus;
I am thinking of things as time passes on, I came up with this really quick after you mentioned that, because I plan on making compiler switches and linker switches done in this manner, by typing Compiler.Whatever or Linker.Whatever. (I want to eliminate the preprocessor as well - I think I have a viable solution for that as well thought of)
East or west VC is the best. :)
Good luck then James. Make it available in less than 10 years. I maybe able to help as Beta Tester. :)Quote:
Originally posted by JamesSchumacher
I am thinking of things as time passes on, I came up with this really quick after you mentioned that, because I plan on making compiler switches and linker switches done in this manner, by typing Compiler.Whatever or Linker.Whatever. (I want to eliminate the preprocessor as well - I think I have a viable solution for that as well thought of)
But North or South, it's VB, no doubt :pQuote:
mitesh2005:
East or west VC is the best
Whenever it comes out - just watch for the XCS (Expandable Compiler System.Quote:
Originally posted by aio
Good luck then James. Make it available in less than 10 years. I maybe able to help as Beta Tester. :)
Although I have been a Win32 coder for the majority of my 2.5 years as a programmer, and I have said I would go to Linux - I'm seriously considering another route. I might take my efforts to help what I believe is close to what I would want in an OS and just needs developer support. AtheOS - http://www.atheos.cx - So it's quite possible that some sort of release from me could possibly come earlier (and definitely other applications) for that particular platform. MS may want to depreciate C++ - but atleast I have one place to go to where I have an option.
Stay on topic - I don't agree - I think I like C(++).Quote:
But North or South, it's VB, no doubt :p
VB is on topic. Maybe if he had mention COBOL then :eek:Quote:
Originally posted by JamesSchumacher
Stay on topic - I don't agree - I think I like C(++).
But James we cannot wait 10 years or there about for an OS. Develop the OS and you can marry peacefully thereafter :cool:Quote:
I might take my efforts to help what I believe is close to what I would want in an OS and just needs developer support.