http://erion.tdrealms.com

Hi,
I was considering developing in this engine, but am currently thinking it is a little bit of a waist of time. I haven't heard anything in the way of updates for a hole year, so.
However, i'm not going to give up on it completely. I totally know what developing like this is like, trust me. .

I want it's source code, because it is under the MIT license witch is open source

Hi robjoy,
This is directly concerning DFE because I would like to discuss the compiler and how its going to work. there are a few things you must know in order to write a compiler.

You must know assembly language. For instance, you must know what a very simple program is in assembly language. This is a very simple file that does nothing, but contains the code
int main()
{
}
in assembly language. If you want to write a compiler, you must know what the following assembly source does
    .file    "asmtst.c"
    .def    ___main;    .scl    2;    .type    32;    .endef
    .text
.globl _main
    .def    _main;    .scl    2;    .type    32;    .endef
_main:
    leal    4(%esp), %ecx
    andl    $-16, %esp
    pushl    -4(%ecx)
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %ecx
    subl    $4, %esp
    call    ___main
    addl    $4, %esp
    popl    %ecx
    popl    %ebp
    leal    -4(%ecx), %esp
    ret
Now this might seem easy, just paste it in! But there are a few things you must also know in order to do anything useful. Here is a simple hello world program in C, then assembly language:
C:
#include <stdio.h>

int main(int argc, const char* argv[])
{
printf ("Hello world!\n");
}

Assembly language:
    .file    "asmtst.c"
    .def    ___main;    .scl    2;    .type    32;    .endef
    .section .rdata,"dr"
LC0:
    .ascii "Hello world!\0"
    .text
.globl _main
    .def    _main;    .scl    2;    .type    32;    .endef
_main:
    leal    4(%esp), %ecx
    andl    $-16, %esp
    pushl    -4(%ecx)
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %ecx
    subl    $4, %esp
    call    ___main
    movl    $LC0, (%esp)
    call    _printf
    addl    $4, %esp
    popl    %ecx
    popl    %ebp
    leal    -4(%ecx), %esp
    ret
    .def    _printf;    .scl    2;    .type    32;    .endef
This does the exact thing in C as the assembler source does. Both do the same thing.
You cannot convert source code to assembly language in lua. That requires another compiler like Gcc.
You must know another high level language like C, C++, fortran, go, objective C, objective C++ or ada. This is a definite requirement.
you must know the registers of the computers CpU architecture. For instance, a 32 bit CPU has eax, ax, etc, while a 64 bit system has rax, rbx etc.
You need to know machine language, or a way to convert the binary created by your compiler into executable, machine language code that can be executed directly without going through an interpreter. Maybe GNU bison would be another, better choice?

You should study these things before even thinking about writing a compiler.

Hi robjoy,
I understand your knowledge. However, if you want to write a compiler, you should know some assembly just in case you need inline asm. For instance, C++ and C have an inline asm support with the asm() method. I forgot the parameters, I'd have to check. How ever, that VM converter. Do you know what VM stands for? Virtual machine. By using that VM converter, you are doing exactly what Java does, it runs code through bytecode. We don't all like byte code because it is slow and has no memory management. You said:
Bison is a parser generator.
You are incorrect there. Bison can generate compilers, too. If you have read the entire bison manual, it only shows you how to generate parsers. It doesn't show you how to generate compilers. However, Bison isn't the best either. No compiler/parser generator is the best.
I talked about machine language. You don't need it, but its recommended. Oh, and before I go, you are quite wrong on some of your statements. Yes, I used -S for GCC to get that output, but I do know assembly. The 'ascii' statement is an assembly instruction. The issue with assembly is that assembly is, as I said, specific for that computer architecture. Another assembly command is 'asciiz', which does similar things as 'ascii'. Note: If you want to write a compiler, try Antlr3. Its tough to learn, but it can generate compilers as well. If you want to talk about this more, just add me to Skype, ethin39, and we'll talk this out.

Hi robjoy,
Sorry for the confusion about that, I didn't mean every java implementation. How about we just forget about this hole compiler stuff and continue with the normal discussion, shall we? You know that we both low the same stuff, and its, in battle comparison, sword against sword, with the exact power in both weapons. Its not possible to beat each other. However, robjoy, I do want to start programming in DFE again, but I'm so busy with everything, DM2 and such, and now I'm learning Vala because it is similar to c#. Otherwise, I'd be glad to talk to you on Skype.
Oh, before I close the discussion on the compiler, that is, the one I started, I have to say, I was write on the byte code. It has to be ran through an interpreter instead of direct execution of the byte code. Look at Python, for instance. That can compile .py code into .pyc, .pyo etc files, but you have to have python installed on your computer to run that program. A newbie isn't going to want to do that, are they? No. That's why I like languages that compile into direct binaries. Its because no interpreter is necessary to run the program. As I've said, interpreters are much slower than compiled programs because they not only directly execute the program, but they have to parse it line by line, which might be good for debugging and syntax error checking, but no one wants to install Python, Ruby, Perl, etc in order to interpret their programs.

Hi,
@SLJ, this is how it sounded to me as well. While I don't mind suggestions, even corrections, since this is an open source project once we release the code, questioning someone's knowledge just because you know something is not going to end well.
I still don't understand how @Ethin got the notion that I was unaware of the techniques, or knowledge about writing or using compilers. Maybe he had an introduction to assembly class, and thought he'd show us how much he learned?
At any rate, I am open to discussions, as always!

Correct. I never said you were wrong concerning bytecode execution.

A programmer, no matter how much of a newbie he/she is, will have to do that eventually. There is no way avoiding it.
As for an end user, I am not sure why you think that they'd have to install an interpreter separately. It is the programmers task to release their program in a proper format. Python programs, such as NVDA, other tools such as BGT, mainstream games having a Lua interpreter, all do that. You don' thave to install anything extra to run them.

This is an interesting insight. It seems then that all the Php, Ruby, Python, Java, HSP, Inform, Euphoria, Smalltalk  programmers, millions of people, are not included in your "noone" category.
Syntax checking and debugging happens even if you are using compilers that produce machine code.
Code interpretation can happen line by line, but nowadays there are far more efficient ways. This is why there are so many people developing lexers and parsers. Bytecode is most certainly not executed line by line. Thus, we cannot really categorise interpreted languages as just slow, line-by-line languages. To write a simple interpreter, line by line interpretation would work, but we are also talking about efficiency, which generates a whole new set of issues. But this is way beyond my post
As for interpreted languages being slow, yes, by nature they are slower than machine code. But quite often their speed is enough where speed is not important, such as scripting a game. Interpreted languages are getting more and more efficient, there are some quite amazing speed comparisons if you take the time to look for them.
Despite their slowness, they have a lot of advantages. Dynamic execution, duck typing, just to mention a few.
Please research this properly, because I really feel that a lot of things you have said are not based on neither experience, nor correct information.
By all means, I am not intending to instruct you. If you are interested, and seemingly you are, you have plenty of time to learn these things properly. One thing I am asking you however: next time, please do not draw conclusions hastily. As you see, they often result in confusion and thus not really contribute to our discussion.
Best of luck with DFE, once you have enough time to "mess" with it. As always, we are here to help, even so, since we are in alpha stage for now!
Rob

OK OK OK OK OK! Robjoy, I must say, you are write here. NVDA, actually, was frozen into an executable. BGT just runs its compilation stages through a VM, exec.bin.
Can we just... please... close the hole thing about the compiler... or take it somewhere else? No, I Had no intention to 'show' you what I knew, I had no idea if you knew any of that; I wasn't testing you at all; I was just trying to ask you in a nice way if you knew any of those things. A compiler does take a while to write, indeed. However, I would like to turn this discussion into what it was before, so, discussion closed. End of compiler discussion, OK?

A few suggestions for DFE though

This raises some interesting questions, rob joy.

First, I haven't taken an assembly class just yet, I have only read books, tutorials etc on it.

Second, as I said before, I had no intention to display my knowledge.

Third, you said that you were going to release the source code. I'd love to check it out, seeing as I am interested in learning new things all the time. I love to learn new programming languages, scripting languages, etc. I like to read, too, so I'd be glad to pick up a copy of that source code once it is released and check it out.

Forth, you said I was "questioning someone's knowledge just because you know something" and that it would "not  end well." I was not questioning anyone.