Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0

    About Dev C++ compiler


    i understand that Dev C++ is a free IDE.
    i want build my own language:
    1 - write the code with my new language;
    2 - translate it to C\C++;
    3 - call the compiler by command line.
    so i need ask:
    1 - how can i have the C\C++ compiler free(like some files and it's independencies)?
    2 - how can i execute it with a command line?

    why not create my own compiler instead these way?
    1 - i don't understand the basics for translate the code(i read something... but i continue without understand how they do it):(;
    2 - these is my best way to do it and more easy;)

    i accept sugestions
  2. #2
  3. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,614
    Rep Power
    1945
    Dev C++ use the MinGW compiler which has its own documentation (HOWTO)

    When you create your own language, you still have to look how to create a parser/lexer for your code.
    Looks like there are some basic information [urlhttp://parsingintro.sourceforge.net/#contents_item_5]here[/url]. But you probably want to search for more.

    There is also a thread this forum: Compiler writing and new language design.
    Last edited by MrFujin; May 31st, 2013 at 02:33 PM.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    thanks for all.
    1 thing: can i share that compiler files with my new language or i have some autor restriction?(sorry, my english is limited and i don't have sure if i can share the files)
    can you resume it for me?

    when i do these:
    "g++ helloworld.cpp foo.cpp -o helloworld.exe" i must have, before, the compiler file name, right?
  6. #4
  7. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,614
    Rep Power
    1945
    Originally Posted by Cambalinho
    thanks for all.
    1 thing: can i share that compiler files with my new language or i have some autor restriction?(sorry, my english is limited and i don't have sure if i can share the files)
    Take a look at the Licensing Terms.

    Originally Posted by Cambalinho
    can you resume it for me?
    What do you mean?


    Originally Posted by Cambalinho
    when i do these:
    "g++ helloworld.cpp foo.cpp -o helloworld.exe" i must have, before, the compiler file name, right?

    Not sure what you mean with "the compiler file name".
    For c++ programming itself, you can create the code in a file called helloworld.cpp. This could for example be the hello world program.
    Then the compiler is used to create the executable file:
    Code:
     g++ helloworld.cpp -o helloworld.exe
    In creation of your own language, you have to create you own compiler which can translate it to the c++ syntax or what else you choose.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by MrFujin
    Take a look at the Licensing Terms.


    What do you mean?





    Not sure what you mean with "the compiler file name".
    For c++ programming itself, you can create the code in a file called helloworld.cpp. This could for example be the hello world program.
    Then the compiler is used to create the executable file:
    Code:
     g++ helloworld.cpp -o helloworld.exe
    In creation of your own language, you have to create you own compiler which can translate it to the c++ syntax or what else you choose.
    i try use these in VB6, but isn't working:(
    Code:
    Shell App.Path & "\MinGW32\bin\gcc.exe -o " & App.Path & "\test.cpp " & App.Path & "\test.exe"
    no exe is created(i have sure the code is ok):(
  10. #6
  11. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,614
    Rep Power
    1945
    -o have to be place after the .cpp fil but before the .exe file.
  12. #7
  13. Commie Mutant Traitor
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Jun 2004
    Location
    Alpharetta, GA
    Posts
    1,806
    Rep Power
    1570
    As I said in my 2009 forum post, it makes sense to learn how to write a simple compiler for a sub-set of an existing language first, to practice your techniques, rather than trying to tackle both compiler design and language design in one go. One of the reasons I say this is because it gives you a known target to shoot for - if you know how the language should behave already, then there are fewer surprises to be had.

    If you are following conventional compiler design - and while alternatives do exist, both with interpreters and compilers, it generally makes sense to follow the well-worn path for something as complicated as this - you will in essence have to 'design' the language you are implementing as a pair of grammars - one for the lexical analyzer, and one for the parser. Here again, the advantage of working with a known source language is clear, especially since most language definitions include a grammar already. For example, here is part of an LL(1) context-free grammar for C, derived from the grammar given in K&R 2nd ed. (the original can be found here; I am using a more conventional form of EBNF rather than the simplified form that post uses):

    Code:
    <terminal> ::=  <typedef-name> 
                       | <integer-literal> 
                       | <character-literal>
                       | <floating-literal> 
                       | <enumeration-constant>
                       | <identifier>
    What this says is, "a terminal is either a typedef name, an integer literal (e.g., 5, 42, etc.), a character literal ('a', 'b', etc.), a floating-point literal, an enumeration constant, or an identifier". It describes the structure of this aspect of the language precisely, but the grammar is only part of the story.

    The really complex part of the compiler is in dealing with the semantics: what the various statements and expressions mean. While a well-designed grammar can solve a lot of the problems with semantics by giving the compiler an unambiguous path to follow, you still have to turn the grammar elements into specific statements in the target language (that is, the language you are translating the source language into, usually an assembly language of some sort but in your case C).

    So, unless you have some very specific ideas of how your language is going to work, you may find it easier to start off with a simpler language and go from there.

    Comments on this post

    • zxq9 agrees : As an aside, a great primer on grammars and parsing is "info bison" on a *nix system.
    Rev First Speaker Schol-R-LEA;2 JAM LCF ELF KoR KCO BiWM TGIF
    #define KINSEY (rand() % 7) λ Scheme is the Red Pill
    Scheme in Short Understanding the C/C++ Preprocessor
    Taming Python A Highly Opinionated Review of Programming Languages for the Novice, v1.1

    FOR SALE: One ShapeSystem 2300 CMD, extensively modified for human use. Includes s/w for anthro, transgender, sex-appeal enhance, & Gillian Anderson and Jason D. Poit clone forms. Some wear. $4500 obo. tverres@et.ins.gov
  14. #8
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by Schol-R-LEA
    As I said in my 2009 forum post, it makes sense to learn how to write a simple compiler for a sub-set of an existing language first, to practice your techniques, rather than trying to tackle both compiler design and language design in one go. One of the reasons I say this is because it gives you a known target to shoot for - if you know how the language should behave already, then there are fewer surprises to be had.

    If you are following conventional compiler design - and while alternatives do exist, both with interpreters and compilers, it generally makes sense to follow the well-worn path for something as complicated as this - you will in essence have to 'design' the language you are implementing as a pair of grammars - one for the lexical analyzer, and one for the parser. Here again, the advantage of working with a known source language is clear, especially since most language definitions include a grammar already. For example, here is part of an LL(1) context-free grammar for C, derived from the grammar given in K&R 2nd ed. (the original can be found here; I am using a more conventional form of EBNF rather than the simplified form that post uses):

    Code:
    <terminal> ::=  <typedef-name> 
                       | <integer-literal> 
                       | <character-literal>
                       | <floating-literal> 
                       | <enumeration-constant>
                       | <identifier>
    What this says is, "a terminal is either a typedef name, an integer literal (e.g., 5, 42, etc.), a character literal ('a', 'b', etc.), a floating-point literal, an enumeration constant, or an identifier". It describes the structure of this aspect of the language precisely, but the grammar is only part of the story.

    The really complex part of the compiler is in dealing with the semantics: what the various statements and expressions mean. While a well-designed grammar can solve a lot of the problems with semantics by giving the compiler an unambiguous path to follow, you still have to turn the grammar elements into specific statements in the target language (that is, the language you are translating the source language into, usually an assembly language of some sort but in your case C).

    So, unless you have some very specific ideas of how your language is going to work, you may find it easier to start off with a simpler language and go from there.
    how can i start if i don't understand how begin:(
    i understand that the compiler do object file and the link combine the object file with libraries and give us the exe.(the interpreter is another story, compile the code line by line for we test the code). the big question remains: what is object code? what is exe code?(of course, if i open the exe by notepad, i don't see 0's and 1's lol)
    (are these 2 questions the make me confuse)
  16. #9
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by MrFujin
    -o have to be place after the .cpp fil but before the .exe file.
    i continue without see the exe file:(
    the command window open and then close it... i can't see what is there, because is to fast:(
    but i now the C++ is correct.. with no errors.
    Code:
    Private Sub mnuCompileCompile_Click()     
      Dim strCompilerName As String     
      Dim strCPPFonteName As String     
      Dim strEXEFileName As String     
      strCompilerName = App.Path & "\MinGW32\bin\gcc.exe"
      strEXEFileName = App.Path & "\test.exe"     
      strCPPFonteName = App.Path & "\test.cpp"
      RichTextBox2.SaveFile App.Path & "\test.cpp", rtfCFText
      'Shell strCompilerName & strCPPFonteName & strEXEFileName
      ShellExecute Form1.hwnd, "open", strCompilerName, strCPPFonteName & " -o " & strEXEFileName, App.Path, 1 
    End Sub
    (these continue be VB6 code)
    but what i'm doing wrong?
  18. #10
  19. Commie Mutant Traitor
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Jun 2004
    Location
    Alpharetta, GA
    Posts
    1,806
    Rep Power
    1570
    Originally Posted by Cambalinho
    how can i start if i don't understand how begin:(
    i understand that the compiler do object file and the link combine the object file with libraries and give us the exe.(the interpreter is another story, compile the code line by line for we test the code). the big question remains: what is object code? what is exe code?(of course, if i open the exe by notepad, i don't see 0's and 1's lol)
    (are these 2 questions the make me confuse)
    Actually, many or even most compilers produce assembly code of some sort, which is then passed to an assembler, and that produces the object file, etc. You simply don't see that step because it's internal to the compiler driver program, which connects the various parts of the development tools such as the compiler, assembler and linker so that they all act in a single step. Still, you really ought to know about object formats and executable formats, at least the principles behind them.

    As I explained in a recent post in another forum, the object file is a mix of the machine code for the program, and additional information about relocation, external references, and so forth. Now, the machine code part isn't exactly machine code, because most of the address references are replaced with a sort of placeholder, which instead of the actual address, holds a table reference to another part of the object file. This is important, because the loader - the part of the operating system that loads program code into memory - doesn't necessarily put the program in the same location every time.

    Now, as you pointed out, it is the job of the linker to turn the object file into an executable file. One thing to understand is that a program may have several separate object files, which have to be combined - linked - into the executable program. In addition, almost every program calls on standard functions from library archives, a special case of an object file that contains code which is used in several programs. The conventional libraries are static; the linker takes a copy of the library code and puts into into the executable file directly. However, on modern systems, many if not most of the most commonly used libraries are shared libraries, also called Dynamically Linked Libraries (DLLs) in Windows terminology. The code in the DLL stays outide of the executable program, and only gets linked to the program 'on demand' by the loader when the program needs it. This means that several programs can share the same copy of the library, saving memory and making the executable files smaller.

    The main thing the linker does is combine the object files for the program with the object code in the libraries, putting them together into a single piece which can be loaded into memory. Now, in most systems, the executable file still isn't quite just machine code; it still has the placeholders where addresses go, as well as additional information about external references to DLLs, how much memory the program needs, the data constants, and so forth.

    It is only when the loader loads the program that it finally becomes actual machine code. Even then, the DLLs may or may not be loaded into memory until they are actually used by one of the programs which calls on them.

    For a more detailed explanation of linkers, executable formats, and so forth, see the online textbook Linkers and Loaders by John Levine, or get a copy of the book itself if you can find it.

    As for why you don't see ones and zeros when you try to look at the executable file in Notepad, the reason is simple: Notepad is trying to read the file as character data, and doesn't know that it is a 'binary file'. One thing you have to understand is that the difference between a 'text' file and a 'binary' file is quite arbitrary: Character data [b]is[/i] binary data, just in a particular format. All files are really 'binary files', it's just that the ASCII text (and it's successor, Unicode UTF-8) format is so pervasive that it is often treated as something unique unto itself. To see what I mean, just consider the difference between the 'binary' number 3 and the ASCII digit '3' in the ASCII table. Now, since Notepad is expecting character data, and tries to interpret the bytes as characters; but since many of the 'characters' are in the parts of the table with no visible character representations (called 'glyphs'), all Notepad can do is put a placeholder where the byte in question is.

    To see the data as binary - which is generally pointless, as reading a series of binary values is a mind-numbing exercise - you would need a program that turns each byte into a string of '1' and '0' characters. Since humans have a lot of difficulty reading something like binary, it is more common to represent the bytes as hexadecimal numbers, which line up with the sizes of byte values much better than decimal numbers and are still readable (with practice) by mere humans. Son, instead of eight digits to represent the largest byte value possible - 11111111 - you would have two hex digits - FF. It takes some practice, but reading hex values isn't difficult to do, and quickly becomes second nature if you are doing it for very long. There are many hex editors available for Windows (including a plug-in for Notepad++, which I heartily recommend BTW), and virtually all debuggers have a hex viewing feature as well.
    Rev First Speaker Schol-R-LEA;2 JAM LCF ELF KoR KCO BiWM TGIF
    #define KINSEY (rand() % 7) λ Scheme is the Red Pill
    Scheme in Short Understanding the C/C++ Preprocessor
    Taming Python A Highly Opinionated Review of Programming Languages for the Novice, v1.1

    FOR SALE: One ShapeSystem 2300 CMD, extensively modified for human use. Includes s/w for anthro, transgender, sex-appeal enhance, & Gillian Anderson and Jason D. Poit clone forms. Some wear. $4500 obo. tverres@et.ins.gov
  20. #11
  21. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,614
    Rep Power
    1945
    Console application does close down when it is completed. You should start a command window and then start your program from there to see result.

    What is the content of the App.Path?
    Does it work if you run the compiler from the command window manually?
  22. #12
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by Schol-R-LEA
    Actually, many or even most compilers produce assembly code of some sort, which is then passed to an assembler, and that produces the object file, etc. You simply don't see that step because it's internal to the compiler driver program, which connects the various parts of the development tools such as the compiler, assembler and linker so that they all act in a single step. Still, you really ought to know about object formats and executable formats, at least the principles behind them.

    As I explained in a recent post in another forum, the object file is a mix of the machine code for the program, and additional information about relocation, external references, and so forth. Now, the machine code part isn't exactly machine code, because most of the address references are replaced with a sort of placeholder, which instead of the actual address, holds a table reference to another part of the object file. This is important, because the loader - the part of the operating system that loads program code into memory - doesn't necessarily put the program in the same location every time.

    Now, as you pointed out, it is the job of the linker to turn the object file into an executable file. One thing to understand is that a program may have several separate object files, which have to be combined - linked - into the executable program. In addition, almost every program calls on standard functions from library archives, a special case of an object file that contains code which is used in several programs. The conventional libraries are static; the linker takes a copy of the library code and puts into into the executable file directly. However, on modern systems, many if not most of the most commonly used libraries are shared libraries, also called Dynamically Linked Libraries (DLLs) in Windows terminology. The code in the DLL stays outide of the executable program, and only gets linked to the program 'on demand' by the loader when the program needs it. This means that several programs can share the same copy of the library, saving memory and making the executable files smaller.

    The main thing the linker does is combine the object files for the program with the object code in the libraries, putting them together into a single piece which can be loaded into memory. Now, in most systems, the executable file still isn't quite just machine code; it still has the placeholders where addresses go, as well as additional information about external references to DLLs, how much memory the program needs, the data constants, and so forth.

    It is only when the loader loads the program that it finally becomes actual machine code. Even then, the DLLs may or may not be loaded into memory until they are actually used by one of the programs which calls on them.

    For a more detailed explanation of linkers, executable formats, and so forth, see the online textbook Linkers and Loaders by John Levine, or get a copy of the book itself if you can find it.

    As for why you don't see ones and zeros when you try to look at the executable file in Notepad, the reason is simple: Notepad is trying to read the file as character data, and doesn't know that it is a 'binary file'. One thing you have to understand is that the difference between a 'text' file and a 'binary' file is quite arbitrary: Character data [b]is[/i] binary data, just in a particular format. All files are really 'binary files', it's just that the ASCII text (and it's successor, Unicode UTF-8) format is so pervasive that it is often treated as something unique unto itself. To see what I mean, just consider the difference between the 'binary' number 3 and the ASCII digit '3' in the ASCII table. Now, since Notepad is expecting character data, and tries to interpret the bytes as characters; but since many of the 'characters' are in the parts of the table with no visible character representations (called 'glyphs'), all Notepad can do is put a placeholder where the byte in question is.

    To see the data as binary - which is generally pointless, as reading a series of binary values is a mind-numbing exercise - you would need a program that turns each byte into a string of '1' and '0' characters. Since humans have a lot of difficulty reading something like binary, it is more common to represent the bytes as hexadecimal numbers, which line up with the sizes of byte values much better than decimal numbers and are still readable (with practice) by mere humans. Son, instead of eight digits to represent the largest byte value possible - 11111111 - you would have two hex digits - FF. It takes some practice, but reading hex values isn't difficult to do, and quickly becomes second nature if you are doing it for very long. There are many hex editors available for Windows (including a plug-in for Notepad++, which I heartily recommend BTW), and virtually all debuggers have a hex viewing feature as well.
    thanks.. realy... thanks
  24. #13
  25. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by MrFujin
    Console application does close down when it is completed. You should start a command window and then start your program from there to see result.

    What is the content of the App.Path?
    Does it work if you run the compiler from the command window manually?
    thanks for the tip.
    heres the print screen:
  26. #14
  27. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by Cambalinho
    thanks for the tip.
    heres the print screen:
    with more tryies, i did it;)
    "gcc -o Filename filesource.cpp"
    but:
    Code:
    Private Sub mnuCompileCompile_Click()
       Dim strCompilerName As String
       Dim strCPPFonteName As String
       Dim strEXEFileName As String
       strCompilerName = App.Path & "\MinGW32\bin\gcc.exe"
       strEXEFileName = App.Path & "\test.cpp"
       strCPPFonteName = App.Path & "\test "
       RichTextBox2.SaveFile App.Path & "\test.cpp", rtfCFText
       ShellExecute Form1.hwnd, "open", strCompilerName, "-o " & strEXEFileName & strCPPFonteName, App.Path, 1
    End Sub
    so what is the string problem?
  28. #15
  29. Lord of the Dance
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2003
    Posts
    3,614
    Rep Power
    1945
    can you try to post the complete command with all there parameters?

    The standard is to have the source before the program name:
    Code:
    gcc <path>\mySource.cpp -o <path>\myProgram.exe
    If you have space in the path, you should add " " around it:
    Code:
    gcc "<path with spaces>\mySource.cpp" -o "<path with spaces>\myProgram.exe"
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo