Designing A Language

[cman]

Thank you for your input rea!  :U Sorry I haven't responded for awhile, I've been busy. In this language I wanted to "bridge the gap" between how assembler is input and how assembler is considered by an assembly language programmer. When I program assembler I think things like; "load this register with this value and the other with this value , sum the two and move this value to a memory location for storage and future use". I think this is how every programmer considers an algorithm in the primary stages of development. Thats essentially what I whated to do with this language. I think for the most part that the expressions in the language would be short cuts to mnemonics , with additional code generation that is  not implied for statements and symbols where such things that can be generated in an "algorithmic way" ( where no intuition whatsoever is required to generate the proper instructions for the given situation ). Thats my entire premise for the "language". Thank you for your time , tree diagrams , ideas , ect.  :U 

[tenkey]

When I program in assembly language, my thoughts start with a task, such as "I need to add two numbers", followed by "this processor forces me to use a register" or "this processor forces me to do everything through the one register called the accumulator". So I generate a load instruction (in x86, it's one form of "MOV"). Then I think "I can add the second value directly from memory" or "I must load the second value into a register, then add", and generate the appropriate instructions.

I do this for all processors, and all languages. First, the task, followed by possible ways of implementing it, followed by choice (if there is more than one viable way.)

[cman]

Then, the question that I have, is how you will handle operators?... like a shorcut to mnemonics? or like "they are"

for example

Code Select Expand



b+c
follow a temp var a
a = b + c

is diferent than

b+c
follow a rewrite of the first operator
b = b + c


The first example, is like I say, the operator "+" uses a temp var that can be "deleted" with optimization (considering that the result of a push is at [esp], but is the same than the operator... tough you will normally push for save and resuse the register...), the second one, is more a shorcut to asm.

I was thinking in the case of statements like :

Code Select Expand



  eax = eax + ebx;


that the compiler would set up temporary memory storage for the value of eax . I think that there are certain instances where it would be feasible for the compiler to do this , and this would be part of the "high level" features avaliable to the programmer. I don't think that the compiler should alter the contents of registers in any way , as this could corrupt an assembly language programmer's algorithms.

Code:
            =
           / \
          /   \
    ecx(r32)   |(s2) = ecx
              /   \
             /     \
     ecx = +(s1)   edx(r32)
          /  \
         /    \-----> mov ecx, [esp]/ebx
    eax(r32)   push (mem32 [esp])
                \
                 \
                ebx (r32)

In this case, I guess can be generated well.



Code:
push ebx
mov ecx, [esp]/ebx (taking the shortcut about push result equal operator)
add ecx, eax
or ecx, edx

I think that the statement:

Code Select Expand



   ecx = ( eax + ( push ( ebx ) ) ) | edx;


would generate the simpler :

Code Select Expand



   push ebx
   mov ecx , eax
   add ecx , ebx
   or ecx , edx



as when the instruction push is executed the next operator will operate on the data or register contained within the braces, push  ( ebx )  , if there is no alteration of the data or register as a side effect of the operation. I'm still working finishing the grammar. I'm amazed at the level of work involved in this project! :eek As soon as I have something completed and debuged and make sure that the language can express what I mean it to express , I can get on to the business of generating intermediate results and figure out code generation issues. Thanks again for your input! This is always helpfull to me! :U

[cman]

When I program in assembly language, my thoughts start with a task, such as "I need to add two numbers", followed by "this processor forces me to use a register" or "this processor forces me to do everything through the one register called the accumulator". So I generate a load instruction (in x86, it's one form of "MOV"). Then I think "I can add the second value directly from memory" or "I must load the second value into a register, then add", and generate the appropriate instructions.

I do this for all processors, and all languages. First, the task, followed by possible ways of implementing it, followed by choice (if there is more than one viable way.)

Yeah , I want to "formalize" this process in terms of a mathematic / symbolic language that could express the process in more "human" terms than the tiny machine steps that are involved in an assembly language program , but still retain the efficiency and power of assembly language programming. I'd like the translator to be able to do the little annoying things for the programmer , like set up memory for strings , temporary variables and handle mathematical expressions. I always liked the way that C used operators perform many algorithmic tasks , so I thought it might be neat if this sort of thing could be used to create an assembly language - like translator. I'll have to keep thinking about this! :bg