have you all seen this yet? http://www.vbforums.com/showthread.p...35#post2167435
although not in english, you may find this useful
Printable View
have you all seen this yet? http://www.vbforums.com/showthread.p...35#post2167435
although not in english, you may find this useful
TIP: design the compiler to consist of a back end and a front end, which communicate some abstract language representation. The front end parses the source, the back end generates the assembly. This is the way every other compiler works, and it lets you, for example, relatively easily port the thing to other platforms, or simply to a different assembler. It also allows you to write, should you ever want such a thing, a late-code-generating linker, which is the requirement for global program optimizations such as what the newer versions of VC++ do.
I wonder if chem is gonna get a compiler book as well. Would be nice to have two books that will help lead us in the right direction.
Funny you should say that JR. Yesterday I ordered an ASM book and then a few hours later MrPolite recommended an ASM book ... the same one! How spooky is that?
Does your compiler book give you all the different EXE formats? There are about 6 different kinds if memory serves me.
I could try Jacob, but since I don't work (being 16 and all), I'm not too sure.
Maybe order one off the internet for cheap.
chem
I'd like to order a compiler book too but I don't have time to read it and stuff. I barely have time to learn ASM and do the library functions.
Penagate, can you explain the difference between wide strings and BSTR? I never got around to reading the link you posted. Maybe I'll do that now. I think our choice on strings will be very important, especially when it comes to making the string libraries.
BSTR is just a special form of a wide string, one that stores the length in the word before the start AND is 0-terminated.
The string libraries should work on everything out of mere principle.
What are the advantages/dis-advantages of each?
Right now it seems that there are only two in the book I got. Interpreted and Compiled. But it helps a lot in scanning, parsing, and many other things. It's mostly code rather than theory, and they are using C++ to compile Pascal files as an example throughout the book, and can be changed into any language you want, even the ones you invented. I may need to go to the library or a book store and see what else I can find.Quote:
Originally Posted by wossname
So are you saying the book doesn't have everything we need?
Things I am currently working on:
Finding a good program to make help files in. The one by microsoft is complicated and there are other free ones out there.
Some editors let you edit text in a RTB editor and it produces the HTML and compiles it all for you (WYSIWG editor). I think I might go that direction to avoid the HTML/CSS hassle, but I don't know if the programs I am looking at allow stylesheets (which would save more time in the long run.
No, but it has a lot to get us started. And it has become a big help for me so far. The book was made back in '96, but should suffice for now until we need to add certain things.Quote:
Originally Posted by eyeRmonkey
EXE formats, as in a.out, coff, DOS, DOS-COM, PE/Win32, PE/OS2, elf and others - most OSs have their own, although elf is quite omnipresent in the Unix world lately.
Interpreted vs compiled is something entirely different.
Ok I've done quite a bit of reading so far, and decided to skim through the book. I think the compiler only compiles to .obj files. But I see nothing on having the .obj files converting into an exe. I may have to buy another book to see how it's made into a win32 or DOS exe. At least the book is gonna help me a great deal on everything else.
After I finish documenting as much as I can I want to put the focus back on the lists that CornedBee brought up.
You use a linker to make an exe out of .obj files.
That is the standard build process.
Source - [Compiler] - > (Multiple) OBJ files - [Linker] - > Single EXE/DLL/etc. file.
There are a wide variety of linkers around. Don't feel that you have to create one yourself. You could use the one that comes with VB6, or VC++.
Or the one that comes with the free MS toolkit.
does gcc include a linker?
It would have to. I haven't used it before, but doesn't it result in EXE's? If so, the linker is there..
chem
How would I be able to make my own?
GCC itself does not include a linker. It emits assembly files. It then relies on an assembler and a linker being available, which it invokes for the assembling and linking steps. The GNU assembler (gas) and linker are part of the GNU binutils package.
The MinGW port includes the binutils, so that a linker is available.
If you want to write a linker yourself you need to understand both the object file format you want to link and the executable format you want as a result. The first step is to simply put all code into a single file. Then you walk through the code and resolve the linker references that the assembler put in. Those are placeholders for addresses that only the linker can determine. For the more complicated executable formats (PE, ELF) the linker must then generate relocation tables for all symbols (in case the file can't be loaded to the desired memory location).
There's some more stuff a linker must do, especially in C++: kicking out duplicate code, for example. (That's a result of the template mechanism.)
Maybe you guys should start to take donations so you can afford that stuff ;).Quote:
Originally Posted by chemicalNova
You could save your allowance, or try getting a job. You're old enough. Might find one on eBay real cheap. Just be sure there's something on compiling into a Win32 exe, and has source code on linkers. Those will come in handy.Quote:
Originally Posted by chemicalNova
Once again I'd like to raise the point: Which ASM compiler are we going to ship with LF? We need a free redistributable one (GCC/GNU/Cygwin/WinG?). I think it would be best to use the same compiler from the start.
I think if we use C++/MASM now and a different ASM compiler later on, we will encounter problems, but I could be wrong. I know most x86 ASM compilers are the same, but there has to be some differences, right? And those differences could cause errors.
Don't forget about a linker. I'm still trying to figure out where to find one, or source code to make one.
I was thinking of just using ASM in C++ rather than using MASM, GCC, or whatever. As long as we have access to the x86 instruction set, not to mention be able to use SIMD, then what's to fuss about?
These two links alone will help me somewhat with knowing the bare bones of exes:
http://www.madchat.org/vxdevl/papers...ile/pefile.htm
http://www.thecodeproject.com/win32/vbdebugger.asp
Just need to figure out how to get the compiler and linker to convert it to this.
Oh and chemical nova hooked me up with this:
http://compilers.iecc.com/crenshaw/
2 things:Quote:
Originally Posted by Jacob Roman
1) I think the __asm{} part of C++ is MASM (if you are using Vis Studio).
2) We can't redistribute the ASM compiler within C++ when we release LF. We need to be using an ASM compiler and linker that we can reditribute.
What do you mean we can't redistribute it? Of course we can.
Okay, one of us is missing something, maybe its me. Here is how I am viewing things (assume LightFusion is made and done):
Code is written in LF IDE
-> Code is sent to an interpreter (which outputs ASM)
-> ASM is sent to an ASM compiler (point which I will discuss below)
-> ASM compiler outputs object files
-> Linker puts object files into EXE
When the ASM is sent to a compiler, we need to be using a compiler that we can redistribute. Same goes for the linker.
Do you see what I mean now?
Here is an updated version of the .chm. Let me know what you think.
Just two lines on terminology:
You send code to a compiler that outputs assembly.
You send assembly to an assembler that outputs object code.
So there's no "asm compiler", and an "interpreter" doesn't output code.
Thanks CornedBee. :)Quote:
Originally Posted by CornedBee
Once again, I am very new to this.
Doesn't an interpreter change code from 1 type of code to another. IE - From LF to ASM?
No, an interpreter doesn't change code, it executes it as it is. The CPU "interprets" machine code. The JavaVM sometimes interprets bytecode. The Rhino engine interprets JavaScript.
Everything that changes one form of code into another is called a compiler (unless it's a preprocessor - a preprocessor doesn't understand all the code it handles, only parts of it, and passes the rest unchanged through to the output). A C++ compiler converts C++ code to Assembly (or possibly C, to be again compiled by a C compiler). A Haskell compiler converts code to Assembly (or again C - it's a popular compilation target). An assembler (which is actually a compiler, although it's not called that) converts assembly to machine code.
The edges are blurred, though. The .Net CLR should be called an interpreter based on what it does (executing .Net IL), but its inner technology is based on JIT compiling, so it's a compiler internally. Same applies in some situations to the JavaVM. The Rhino JavaScript engine is capable of compiling some JavaScript to Java bytecode. The PHP interpreter can compile PHP to bytecode. The Perl interpreter can compile scripts to bytecode. The Haskell interpreter Hugs compiles files before executing them.
Thanks. :)
That clears it up nicely for me.
One more question on the topic (for now :)): Are bytecode and machinecode the same thing?
Jake, are you ok with "making your programming dreams come true" as our unofficial motto for now?
Here is an ASM tutorial I found at school the other day:
http://www.drpaulcarter.com/pcasm/index.php
(scroll to the bottom to download the PDF or PostScript formats of the book)
Its shorter than AoA and will give me a good overview. I will still read AoA, but just later.
You guys might want to decide soon. Different instruction sets have different registers, and different functions with different uses. If you want any help apart from you two, we kinda need to know whats going to happen :)
chem
- Each CPU supports specific instruction sets. Assemblers must also support those instruction sets, but they are the same. An x86 assembler produces x86 machine code which runs on an x86 CPU.
- The way we are discussion the compiler you'd think we had finished the language. Yet I don't even know the half of what it's supposed to be like yet...
Also, different Assemblers, no matter what their final CPU support, have different syntaxes.
chem