Printable View
But the thing is, this language is not gonna look completely like C++. It's gonna look like a cross between VB and C++, with a twist of my own style. Or maybe your styles if you suggest any.Quote:
Originally Posted by CornedBee
I just headed down to Barnes & Noble bookstore today, and they didn't have any book on writing compilers so they are preordering this book for me:
http://images.amazon.com/images/P/04...CLZZZZZZZ_.gif
I should have it within 3 to 8 buisiness days. :)
I did it in assembly already... look further up :)Quote:
Originally Posted by Jacob Roman
These sort of things should go in the library. A factorial isn't an operator, it is a mathematical function, hence, factorial() :)
Great list of x86 instructions here:
http://nasm.sourceforge.net/doc/html/nasmdocb.html
It's geared toward NASM but the instructions are the same.
I'm using www.artofassembly.com . It seems to be easier to learn assembly on this site more than anything, especially from their online books.
You still using MASM?
I'm finding it very easy to use inline ASM in VC++. Just compile it as a DLL, export the functions and call them from VB. Quickest way to test them out. Plus, the VC++ compiler handles all the function calling and the stack for you.
Does the VC++ compiler point out ASM mistakes? Like trying to put a DWORD into a low register?
chem
Yeah. It bitched when I used mul with 32-bit registers, and compiled when I switched it to imul (learning an instruction in the process) :)
Wouldn't it be quicker to just call it from C++ then, then you don't need to compile it to a DLL nor fire up VB...Quote:
Originally Posted by penagate
- ØØ -
I can't be bothered creating a GUI to quickly test my functions :DQuote:
Originally Posted by NoteMe
Plus, I presume the library is gonna be a DLL initially anyway, and then static linked into the EXEs later when the compiler is going.
Why a GUI? Do it on console.
I'll do it later when benchmarking the things.
Anyway, it still needs to be a DLL.
I'm kinda lost as to how you guys are doing this. Are you going to write the final executables? Or like CornedBee translate your language into ASM then let another compile it? If the latter, I'd go for MASM, as it supports macros and stuff, which really could come in handy for you.
Jacob:
If you're going to do it the hard way :p, I'd suggest another book. I can't remember the name, but it had a yellow tiger on the front, and the language you end up creating was TigerC or something similar. A search for books like you did above might bring this one up. It really was very in-depth. I picked it up at a University book shop and understood what the author was talking about just by reading the middle two pages (ok, maybe more). I haven't read the one you posted, it might be better, just thought I'd let you know :D
chem
The book I'm getting is what's gonna teach me how to make a compiler, and hopefully my own programming language. They even got stuff on Lexical Analysis.
We also need to have % (modelus (sp?)) operator. I can't even find it in VB (what reference do I need to add?). If you are going to add integer division (\) to a language then why the heck don't you add %?
It's called mod in VB.
Oooooh, wait, The reason I couldn't find it is because I was looking for mod() in the Object Browser instead of doing 10 mod 3. Thats how it should go right?
Yep.
Do you want that as an operator or a funciton? If a function then I can write it in the library. Otherwise, Jake can add it into the compiler.
Going back to logical opperators, are we gonna have separate bitwise and logical Nots, And's etc. ? or will they be the same like in VB.
What calling convention do you guys want to use. I'm leaning toward fastcall because it lessens the ASM instructions needed to write the library functions :) you pass the first two or three (or four?) parameters in the registers instead of the stack.
Also we need to find some powerful language features. Otherwise it will just turn out like any other language, just with a decent (or half-baked, depending how it goes) library :D
Lexical analysis is hardly the hardest part of your endeavour though :)Quote:
Originally Posted by Jacob Roman
chem
Heh heh heh... I love ASM :)
Code:5,000,000 iterations at real time priority
Compiled from VB with all advanced optimisations.
15 ^ 7 : 1438 ms
powI(15, 7) : 328 ms
Bear in mind that there is the overhead of calling the DLL every time, which makes VB's built in routine look all the more horrible :D And I haven't even tried optimising it. Just to give you (especially Jacob ;)) a taste of the sort of speed increase we can expect over VB.Code:LFAPI int powI(int n, int exp)
{ __asm {
mov eax, n ; num
mov ebx, n ; exp
mov ecx, exp ; counter
cmp ecx, 0
je retOne
cmp ecx, 1
je retVal
loopstart:
imul eax, ebx
dec ecx
cmp ecx, 1
jg loopstart
retOne:
mov eax, 1
retVal:
} }
I'm impressed penagate :D
All the string functions like replace() mid() instr() would fly written in Inline ASM.
Want to test something for me? I haven't used Inline ASM with a C++ compiler before, so I'm wondering if something like this would work..
Untested. Probably won't completely work due to the fact I use MASM :eek:Code:__asm {
SecondWord Proc uses edi esi lpString:DWORD
mov esi, lpstring
@@: ;<-- thats what I want to test
cmp BYTE PTR [esi], 32
jle nxt
sub esi, 1
jmp @B ;<-- that too
nxt:
mov edi, esi
add esi, 1
@@:
cmp BYTE PTR [esi], 32
jle lpout
add esi, 1
jmp @B
lpout:
}
Do the @@ labels work with the @B and @F jump instructions?
chem
No, it spat out a slew of compile errors. Didn't like the @ symbols nor the word Proc in the first line for some reason. I'm guessing that's the function header, in which case you'd need to rewrite it in C++ syntax. If you want to pass the arguments in registers you need to use __fastcall and I'm not sure which registers exactly it uses. I think it is eax through edx.
That seems kinda limited in my view.
The @F and @B instructions are great for nubs :D, they simplify the understanding of a simple loop so much (@F being jump forward to the next @@ label, @B being jump back to the previous @@ label).
The extra registers come in handy for graphics routines aswell, if you guys every implement GetPixel and SetPixel like calls for your language.
chem
I meant the fastcall convention when I said eax-edx. I think that is the registers it uses to pass the first four arguments, or something like that. In normal code you can use all of the registers.
Tell me what return type and arguments your proc has and I'll rewrite it to appease the VC++ assembler :)
The only argument is a DWORD pointer to a string. The return values are in edi and esi (the start of the word in edi, the end in esi. The function find the second word in a sentence :D), and they are 32-bit registers. Does that help?
chem
I changed it to return positions in the string rather than pointers, but for general use you'd use pointers I guess.
edi and esi out values are substituted with int pointer params.
Code:LFAPI void SecondWord(int lpString, int *lStart, int *lEnd)
{
int lT1, lT2;
__asm {
mov edx, lpString
mov esi, lpString
loop1:
cmp byte ptr [esi], 32
je nxt
inc esi
jmp loop1
nxt:
mov edi, esi
inc esi
loop2:
cmp byte ptr [esi], 32
je lpOut
inc esi
jmp loop2
lpOut:
add edi, 2
inc esi
sub edi, edx
sub esi, edx
mov lT1, edi
mov lT2, esi
}
*lStart = lT1;
*lEnd = lT2;
}
Yet again, very impressed :D
I'm curious. When 64-bit stuff starts emerging (or has it already? I'm so behind without my own PC), will we call 64 bit registers like this?
?Code:mov eeax, eedx
eeax = 64 bit
eax = 32bit
ax = 16 bit
al = 8 bit
ah = 8 bit
chem
Instead of using an external DLL, penagate, with all of these functions, let's put it in the exe, only making all of the functions and subs inline. Cause you cannot inline stdcalls from a dll. That way there, it will be way faster.
And I will design the syntax in a Word document during the weekend, and upload it here. eyeRmonkey originally wanted me to post the syntax by copying and pasting his first post from here, but I think the Word document thing is a better idea. And hopefully I should have that book by next week.
Yes it will. I am gonna leave it as a DLL however, because how I see it, it can live in the compiler directory, and the functions used can be static linked i.e. inlined into the final EXE as needed. The calling convention can be changed when I compile the DLL. We would probably use fastcall to allow for inlining.Quote:
Originally Posted by Jacob Roman
Chem, the AMD64 adds another 8 64-bit registers prefixed r instead of e. I haven't found the documentation yet but I think it is rax, rbx, etc.
Jacob, any thoughts on special features you want to add in to the language yet? On top of the standard stuff that we have to implement.Code:IA64 general purpose registers
High 8 Low 8 16-bit 32-bit 64-bit
ah al ax eax rax
bh bl bx ebx rbx
ch cl cx ecx rcx
dh dl dx edx rdx
sil si esi rsi
dil di edi rdi
bpl bp ebp rbp
spl sp esp rsp
r8b r8w r8d r8
r9b r9w r9d r9
r10b r10w r10d r10
r11b r11w r11d r11
r12b r12w r12d r12
r13b r13w r13d r13
r14b r14w r14d r14
r15b r15w r15d r15
penagate, write a routine that can do 32.23 ^ 4.215 and make it faster than the built-in, then I'm impressed.
Alternatively, implement your current routine in VB and you may find that the mere call overhead might crush your ASM routine.
Okay, In VB it gets 78 ms. Happy? :)
Bear in mind though, it's not going to be in a DLL. If the VB version can get 78 ms then the inline ASM version should wipe the floor with it.
As for 32.23 ^ 4.215, wait till I figure out these fp instructions ;)
I didn't really mean post the syntax I just meant convert your first reply into the introductory post with a list of team members and what this project is about because I won't be helping as much when my homework starts stacking up.Quote:
Originally Posted by Jacob Roman
I like the .doc idea. I was thinking the same thing earlier.
Use the .txt I posted to get the histroy/teamlist part and put that in your reply (the first reply that is).
Operator I think. I guess that makes it Jake's job.Quote:
Originally Posted by penagate
What do you mean by "the same like in VB"? How could we do anything different. They will obviously be present in the language though.Quote:
Originally Posted by penagate
Jake, when you are making the .doc for the syntax you should go through the thread and make sure everything that has been suggested so far is at least in there as a note. EX: I just suggested modulus (%) as an operator and not a function.
We don't necessarially have to do everything that is suggested, but lets keep track so we don't have to re-read the thread to get ideas.
As the project progresses, keep adding to the .doc and if you ever get confilicting suggestions, post here and we will hash it out. Does that sound good?
Maybe make a seperate .doc for other suggestions (things that don't directly relate to syntax).
Idea: I think we should make a library function that could print out a number (or string?) in binary. Like bin -> dec. In VB its really slow to do. The function wouldn't be useful all that often, so I guess its not the best idea, but I think it would be nice. Penagate already did it in VB so it shouldn't be too much trouble to write it in assembly (I hope?).
Well if we were to make graphic related functions, I was thinking of doing something that the other languages didn't bother doing, or did it way too slow. Like for example, if you were to have a function called Pixel(hDC, X,Y,Color) to plot a pixel, it will draw a pixel to a backbuffer in memory automatically for you using Direct Memory Addressing. It would be nice to use the video card like DirectX and OpenGL does in this attempt. Then after all the graphic related calls have been made, have a function called Swapbuffers(), and it'll flip the backbuffer to the window you refered to. This will be the fastest method of plotting pixels ever deviced, and it should be as fast as DirectX. You should be able to draw one pixel at a time in a loop and literally fill a 1024x768 sized window, and it be instantanious. That's how it was in the old PC games back in '95 when DirectX didn't even exist. Clearing the backbuffer should be instantanious as well. This attempt should be also done for lines, circles, ellipses, polygons, and pictures.Quote:
Originally Posted by penagate
I like that suggestion Jake.
BTW, I think ! should be used in mass operations as stated earlier and factorial should be a function since it isn't that common.
Also, forms will NOT be called forms. They will be Windows. And can be named like Window1, Window2, etc.
Fair enough. So I think I have asked this a few times, but I am not clear on the answer. Will we allow our users to make forms (windows) like you can in VB or will they have to import the win32 library and do all that by themselves?
Yes you can do that, and doing so will add more code in the code window to create it. So instead of manually typing all that code, it does it for you.
So it will be half VB half C++? As in you have to manually reference the win32 DLL to make windows BUT our IDE will have small wizards (or something to that effect) that will put in all the code for you?
Here is some basic work on a logo (that I am sure we will change later) any suggestions for now?