Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-09

Questions regarding pushing more onto assembler

5 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

I have some questions regarding porting of FPC to another machine type. One of the things I am considering doing is the "pushing" of more of the code processing onto the assembler, and whether this might be a better idea, or if it was thought about and rejected for some reasons and it might be worth noting if it was thought about.

For example, I am thinking that code such as

               if  xray = 5 then
                    do_something
               else
                    do_something_else;

Where 'do_something' and 'do_something_else' could be one line or a BEGIN / END block. This could, with use of a good macro assembler, be handled as something like

IF XRAY,EQ,F5
do_something ; code as
generated
ELSE
do_something_else ; more code
ENDIF

F5 DC F'5' Constant defined

Now, the idea is the IF, ELSE and ENDIF macros will handle the creation of the particular code for testing and such.

There are a number of (already written) macros available to do this, and I think it will reduce the complexity of the compiler (at a slight increase in complexity of the generated code via macros) . I am wondering if there are any thoughts on this idea.

Thank you for your assistance
Paul Robinson
Robinson Telephone Company
Arlington, VA

Reply by email

Jonas Maebe
to Unknown author
Show quoted text 9 lines
Now, the idea is the IF, ELSE and ENDIF macros will handle the creation of the particular code for testing and such. There are a number of (already written) macros available to do this, and I think it will reduce the complexity of the compiler (at a slight increase in complexity of the generated code via macros) . I am wondering if there are any thoughts on this idea.

An obvious downside would be that the internal object writer would still need the functionality to translate these macro's into assembler/machine code. Additionally, the complexity of those constructs isn't that big and is written in an entirely processor independent way (ncgflw.pas), so you do not have to worry about that when porting the compiler.

Jonas

Reply by email

Peter Vreman
Show quoted text 34 lines
I have some questions regarding porting of FPC to another machine type. One of the things I am considering doing is the "pushing" of more of the code processing onto the assembler, and whether this might be a better idea, or if it was thought about and rejected for some reasons and it might be worth noting if it was thought about. For example, I am thinking that code such as if xray = 5 then do_something else do_something_else; Where 'do_something' and 'do_something_else' could be one line or a BEGIN / END block. This could, with use of a good macro assembler, be handled as something like IF XRAY,EQ,F5 do_something ; code as generated ELSE do_something_else ; more code ENDIF F5 DC F'5' Constant defined Now, the idea is the IF, ELSE and ENDIF macros will handle the creation of the particular code for testing and such. There are a number of (already written) macros available to do this, and I think it will reduce the complexity of the compiler (at a slight increase in complexity of the generated code via macros) . I am wondering if there are any thoughts on this idea.

This is not possible with fpc. The compiler is made to generate the instructions itself in a list. See cgobj.pas and cgcpu.pas what is required for a new processor.

Reply by email

Florian Klaempfl
to Peter Vreman
Peter Vreman wrote 39 lines
>I have some questions regarding porting of FPC to another machine type. >One of the things I am considering doing is the "pushing" of more of the >code processing onto the assembler, and whether this might be a better >idea, or if it was thought about and rejected for some reasons and it >might be worth noting if it was thought about. > >For example, I am thinking that code such as > > if xray = 5 then > do_something > else > do_something_else; > >Where 'do_something' and 'do_something_else' could be one line or a >BEGIN / END block. This could, with use of a good macro assembler, be >handled as something like > > IF XRAY,EQ,F5 > do_something ; code as >generated > ELSE > do_something_else ; more code > ENDIF > >F5 DC F'5' Constant >defined > >Now, the idea is the IF, ELSE and ENDIF macros will handle the creation >of the particular code for testing and such. > >There are a number of (already written) macros available to do this, and >I think it will reduce the complexity of the compiler (at a slight >increase in complexity of the generated code via macros) . I am >wondering if there are any thoughts on this idea. This is not possible with fpc. The compiler is made to generate the instructions itself in a list. See cgobj.pas and cgcpu.pas what is required for a new processor.

Preferably arm and sparc because they are the easiest.

Reply by email

Daniël Mantione
to Unknown author: I have some questions regarding porting of FPC to another machine type. One of the things…

Op Thu, 15 Sep 2005, schreef

Show quoted text 12 lines
I have some questions regarding porting of FPC to another machine type. One of the things I am considering doing is the "pushing" of more of the code processing onto the assembler, and whether this might be a better idea, or if it was thought about and rejected for some reasons and it might be worth noting if it was thought about. For example, I am thinking that code such as if xray = 5 then do_something else do_something_else;

The compiler already does use such a structure, i.e. the highlevel (node) code generator calls routines in the backend codegenerator which output the actual assembler instructions.

If you would output a macro instead of the indivudual instructions you would get what you describe. The current approach is at least as flexible though, so I see little benefit.

Daniël

Reply by email