Index
> Projects and Ideas > flat c |
| Author |
|
|
Adam Kachwalla 18 Sep 2007, 06:40
..
Last edited by Adam Kachwalla on 07 Mar 2013, 03:02; edited 3 times in total |
|||
18 Sep 2007, 06:40 |
|
|
BiMode 18 Sep 2007, 13:19
Try me (baimode at gmail).
|
|||
|
18 Sep 2007, 13:19 |
|
|
lehox 18 Sep 2007, 17:56
Well it sound nice.. I'm interested
Write a message to me I would like to try/test it. |
|||
|
18 Sep 2007, 17:56 |
|
|
Adam Kachwalla 18 Sep 2007, 22:18
vid wrote:
Sorry vid. I wrote that first message in a bit of a rush. An example of what I am talking about: Say that we have code like this: Code: if (win=true) { test=test+1; } Code: if (win=true) { Code: CMP [win],0xFF JNE ENDIF19208FC2 Code: test=test+1; Code: INC [test] Code: } Code: ENDIF19208FC2: Code: CMP [!EXP!],!VAL! JNE ENDIF#BLOCK# !?! ENDIF#BLOCK#: If you really want to make the compiler add something after each IF statement (for example, a "statement counter", for debug purposes), edit the code like this: Code: ;LINE NO. #LINE# INC [StatCount] ;Incrememt the statement counter CMP [!EXP!],!VAL! JNE ENDIF## Last edited by Adam Kachwalla on 07 Mar 2013, 02:04; edited 1 time in total |
|||
|
18 Sep 2007, 22:18 |
|
|
mattst88 19 Sep 2007, 03:53
Adam Kachwalla wrote:
I'm sorry if I'm off base, but from this code, you don't know much C. Beyond the strange style (for a C programmer) shown by 'test = test + 1;' instead of test++ or test += 1, you have some obvious errors in those 4 lines. First, you don't check if something is equal to true, since a boolean value is inherently true or false. Moreover, you used the wrong operator (= instead of ==). The code should be Code: if (win == true) But better would be Code: if (win) I hope you are able to write a compiler that accomplishes all you wish, but from your examples I don't see how you could complete it. Or maybe you were saying you would have your compiler check for = instead of == and fix it? Of course, this would obviously be breaking the standard. I'm confused. _________________ My x86 Instruction Reference -- includes SSE, SSE2, SSE3, SSSE3, SSE4 instructions. Assembly Programmer's Journal |
|||
|
19 Sep 2007, 03:53 |
|
|
vid 19 Sep 2007, 09:27
Quote: I wrote that first message in a bit of a rush. An example of what I am talking about: Say that we have code like this: so basically your compiler will "paste together" some editable code templates? So your compiler will not optimize code? Quote: the ability to compile for more than one architecture (x86/IA-32, Intel 64, IA-64), This is normal feature of virtually all compilers. Sometimes you have to invoke different compiler executable, but that is just matter of make script. No need to have same compiler executable for both architectures (altough it is a bit nicer) About USE16, USE32, etc... i can't imagine how you would combine it. For example variable defined as "int" in use16 block will be 16bit, but when referencing it in use32 block as "int" it will be 32bit... as only a one small example |
|||
|
19 Sep 2007, 09:27 |
|
|
0.1 19 Sep 2007, 09:31
why don't you port gcc to your OS?
linus once did that too! and now see where the linux stands! |
|||
|
19 Sep 2007, 09:31 |
|
|
Adam Kachwalla 19 Sep 2007, 10:28
vid wrote:
Actually, I think you have a valid point! What I will do: Instead of "code templates", you can edit the output yourself (compiler will optimize it), before the modules are linked, etc. vid wrote:
vid wrote: About USE16, USE32, etc... i can't imagine how you would combine it. For example variable defined as "int" in use16 block will be 16bit, but when referencing it in use32 block as "int" it will be 32bit... as only a one small example Actually, remember the IA-64 blocks cannot mix USE16, USE32 or USE64. Also, about the combination of USE16, USE32, USE64, the INT's will work like this: Code: #USE16 INT test; //Test is 16-bit test=16; #USE64 INT dtest; dtest=test; //The original 16-bit test will have been expanded to match a 64-bit INT, so that it is possible to move it to the naturally-64-bit dtest. Code: USE16 MOV WORD [test],16 USE64 XCHG BYTE [test+6], BYTE [test+7] BSWAP [test] PUSH RAX MOV RAX,[test] MOV [dtest],RAX POP RAX test DQ ? dtest DQ ? |
|||
|
19 Sep 2007, 10:28 |
|
|
vid 19 Sep 2007, 19:30
Code: XCHG BYTE [test+6], BYTE [test+7] no such instruction Quote: Actually, I think you have a valid point! What I will do: Instead of "code templates", you can edit the output yourself (compiler will optimize it), before the modules are linked, etc. you can do that with existing compilers about mixing of bitness... that means you would have to assign different C type to all existing variables on every "useXX". Also it isn't such easy to decide which type. suppose "long" and "int" are both 32bit in USE32 block, which type will be reassigned to "var1" on following code? Code: use16 int var1; use32 // what type has var1 here/ such ambiguity can be VERY confusing. Also not that you would have to have different headers for every useXX mode, or you will have to have "useXX" in header files. But then, you should have to be able to do restore original bitness at end of header. what about following code? Code: use16 int *a=0 use32 short int *b=a; how do you plan to handle far pointers in 16 bit code? By the way, are you going to make it ANSI C compatible, or some custom C-like language? |
|||
|
19 Sep 2007, 19:30 |
|
|
Adam Kachwalla 19 Sep 2007, 20:51
Well in that case, I cannot make the compiler use variables the way you mentioned, in USE16/USE32/USE64 together. Thanks for pointing all that out vid! I can still use them in a "bootsector" situation:
Code: #USE16 //Bootsector code goes here/ #USE32 //PMode code goes here/ #USE64 //Longmode code goes here/ And it will be an ANSI-C compatible compiler. |
|||
|
19 Sep 2007, 20:51 |
|
|
mattst88 20 Sep 2007, 00:18
I'll post again even though you neglected my entire post before.
int on AMD64 is still a 32-bit memory location, by the way. An int declaration after #USE64 in your code is 64-bits though. |
|||
|
20 Sep 2007, 00:18 |
|
|
vid 20 Sep 2007, 00:20
Quote: I can still use them in a "bootsector" situation: [...] there are still sooo many troubling issues: far pointers, jumps/calls between code with different mode, ordering items in resulting (binary?) file, transfers through different modes. These "useXX" are so far only feature you want not present in existing compilers, and in my opinion it isn't doable. For those few rare cases where you need to mix different code modes in single object, i would really rather use assembly. But if you like, give it a try, still it would be a very good experience  |
|||
|
20 Sep 2007, 00:20 |
|
|
Adam Kachwalla 25 Sep 2007, 04:00
..
Last edited by Adam Kachwalla on 07 Mar 2013, 03:07; edited 1 time in total |
|||
|
25 Sep 2007, 04:00 |
|
|
Adam Kachwalla 30 Sep 2007, 11:43
..
Last edited by Adam Kachwalla on 07 Mar 2013, 02:03; edited 1 time in total |
|||
|
30 Sep 2007, 11:43 |
|
|
RedGhost 15 Dec 2007, 12:09
Hey, don't know if this project is still alive or in planning or what but I have interest in such a C compiler, that is if it can content with PellesC's optimization
 ._________________ redghost.ca Last edited by RedGhost on 15 Dec 2007, 14:50; edited 1 time in total |
|||
|
15 Dec 2007, 12:09 |
|
|
vid 15 Dec 2007, 13:50
Note that it wouldn't be "C compiler" it will be "C-like language"
|
|||
|
15 Dec 2007, 13:50 |
|
|
RedGhost 15 Dec 2007, 14:50
vid wrote: Note that it wouldn't be "C compiler" it will be "C-like language" Oh 
Sorry, I didn't read the post(s) in enough depth. _________________ redghost.ca |
|||
|
15 Dec 2007, 14:50 |
|
|
mattst88 15 Dec 2007, 22:25
He completely ignored my post about him possibly not even knowing C.
|
|||
|
15 Dec 2007, 22:25 |
|
< Last Thread | Next Thread > |
Forum Rules:
|