flat assembler
Message board for the users of flat assembler.

Index > Main > FASM for use in Forth cross-compiling

Author
Thread Post new topic Reply to topic
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
I have a few questions about FASM:

1.) Do you have libraries available for console I/O and serial communication, that work under both Linux or Windows? HLA has a library for console programs that would work.

2.) Does FASM have incremental assembly? I already asked about this on comp.lang.asm.x86 and was told "no," but I thought that I would ask here as well.
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e54f416e32cd1a75

3.) I know that FASM has been retargeted for the ARM. Has it been retargeted for anything else (such as the MIPS, for example)? Is FASM designed to be easily retargeted? This usually means that it is table-driven.
Post 16 Nov 2011, 05:56
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
1) Search for fasmlib (vid's project).

2) What do you mean by incremental assembly? fasm can produce .obj files. Is that what you mean?

3) There a various small projects around that target some other architectures. Some with macros (PIC) and some with assembly (ARM). It depends upon what you mean by "easily targeted", compared to what? Have a look at the sources and you will see the tables in there, but in general fasm is not a table based assembler.
Post 16 Nov 2011, 06:08
View user's profile Send private message Visit poster's website Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
revolution wrote:
1) Search for fasmlib (vid's project).


Thanks for the tip regarding FASMLIB. BTW, who is "vid"? Is that the same guy who wrote FASM?

Quote:
2) What do you mean by incremental assembly? fasm can produce .obj files. Is that what you mean?


I explained at length what I meant by "incremental assembly" on clax at that link I provided.

It is possible that the "dynamic linking" that FASM does is what I'm describing. So far, of all the assemblers that I have looked at, that seems to be the most likely candidate for what I want to do.

Quote:
3) There a various small projects around that target some other architectures. Some with macros (PIC) and some with assembly (ARM). It depends upon what you mean by "easily targeted", compared to what? Have a look at the sources and you will see the tables in there, but in general fasm is not a table based assembler.


Well, I suppose I mean compared to GAS. I want my cross-compiler to eventually target a variety of micro-controllers. I can write it so that it assumes that there are 16 general-purpose registers. It can generate code for a generic processor internally, and then make a final pass in which it generates code for the specific processor.

I do need the assembler that I generate code for, to be capable of incremental assembly. Is there a forum somewhere that focuses on GAS internal workings? Maybe somebody has already done something similar to what I want to do.

Note that, even if I generate code for GAS, that doesn't mean that the cross-compiler has to be written in GAS. It could be written in FASM. I have already started writing it in HLA. I don't really want to write it in GAS, because I've heard that GAS has poor error-checking which can cause bad hand-written source-code to generate bad object code without any error message being given (I've run into this with SwiftForth's assembler too).

BTW, on a related note --- Is there a document available providing a reference for the x86? I don't want a tutorial, as I have experience with assembly language --- I just need a reference to refresh my memory, especially on the rarely used instructions.
Post 16 Nov 2011, 09:14
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
vid is a user on this board. Tomasz Grysztar wrote fasm. They are different people.

For the x86 info, read the FAQs (it is sticky and hard to miss) to find the link to the Intel site: http://board.flatassembler.net/topic.php?t=2530 Or just go to intel.com if you can stand the awful navigation there.
Post 16 Nov 2011, 09:22
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
FASM is very fast assembler, so I do not see the need for incremental feature.
I have a big project, yet it still compiles in under 1sec.
Post 16 Nov 2011, 15:09
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
Interesting. I once saw someone using fasm in a way that resembles this a bit.

You can achieve a kind of "incremental dynamic linking" by maintaining a table of function pointers in some known place. I will show it on a very simplified example.

You start with assembling "test.asm" that looks like this:
Code:
; we begin with function table:
function1 dd function1.impl
          rd 99 ; reserve space for another 99 functions

; now the implementations:
use32

function1.impl:

        mov     eax,1
        ret    
(you could also just generate a file which would reserve the space for function table and nothing more)

Then the source, that would attach some new functions to "test.bin" generated this way, would look like:
Code:
virtual at 0      ; pointers to known functions
 function1 dd ?
 function2 dd ?
 ; ...
end virtual

file 'test.bin' ; include previously generated binary

store dword function2.impl at function2 ; update function table with pointer to function implemented here

use32

function2.impl:
        call    [function1]
        inc     eax
        ret    
Post 16 Nov 2011, 19:02
View user's profile Send private message Visit poster's website Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
AsmGuru62 wrote:
FASM is very fast assembler, so I do not see the need for incremental feature.
I have a big project, yet it still compiles in under 1sec.


Part of incremental assembly, is that the data doesn't get clobbered when you assemble and link a new function.

When you are testing your program it generates a lot of data. You notice that a function is not working correctly, so you write a new function. You want to test this new function on the same data that the old function failed on.

If you have to rerun your program and regenerate all of that data, this is going to take more than 1 second --- it is a big hassle for you to do this manually --- and it is likely that you won't generate the data exactly the same as last time, which messes up the whole "scientific method" in regard to testing your theory about why the old function failed.
Post 17 Nov 2011, 04:07
View user's profile Send private message Send e-mail Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
Tomasz Grysztar wrote:
Interesting. I once saw someone using fasm in a way that resembles this a bit.

You can achieve a kind of "incremental dynamic linking" by maintaining a table of function pointers in some known place.


Well, I'm writing a Forth system. I do, in fact, maintain a table of function pointers in a known place --- this is the "dictionary." Traditionally it is a linked list, although a lot of modern system use a hash table, and I personally use a binary tree (see my symtab code in my Forth novice package). Whatever data structure is used, each function has a "header" that maintains information about the function, including its name, where the code is located in memory, and some other stuff as well. The problem is that FASM doesn't know about my dictionary at compile-time.

What you are suggesting, seems to imply that we know ahead of time what functions we are going to write (FUNCTION1, FUNCTION2, etc.) and that we later use STORE to fill in those pointers with the addresses of these functions, when they get written. We don't necessarily know this though. We want to be able to write a function that we hadn't previously considered writing, and be able to add a header for that function to the dictionary given the function's name and address (and other information). Something like your STORE, except that it constructs a header in the FASM symbol table. We want to be able to add new functions to the symbol table, without starting over from scratch with an empty symbol table and constructing the symbol table anew for the entire program.

I have worked with electrical engineers using Forth to test a board. It is common to think up a test function and write it, and then run it and watch the results on an oscilloscope. You don't know ahead of time what functions will be needed --- the electrical engineer thinks this stuff up on the fly and the programmer writes it and runs it --- it is a highly interactive style. This is how I have helped the electrical engineer figure out what the hardware was doing (which is usually not what he expected it to be doing). This has been my experience --- there is no plan! --- you just figure out what you are doing as you do it.

Traditionally, the Forth system was on-board the micro-controller itself, and compilation was done on the micro-controller. This provides interactive development as I have described. The problem however, is that the generated code is pretty inefficient compared to what can be generated by a cross-compiler running on a big desktop computer. Also, there isn't generally a way to link C libraries into Forth programs. I want to have the benefit of a cross-compiler, but I also want to have interactive development as typically provided by an on-board Forth system. I want the best of both worlds!

BTW, let me say that I'm very impressed by FASM. Thanks for writing that and releasing it publicly --- rather than making it closed-source high-dollar software.
Post 17 Nov 2011, 05:01
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
Hugh Aguilar wrote:
What you are suggesting, seems to imply that we know ahead of time what functions we are going to write (FUNCTION1, FUNCTION2, etc.) and that we later use STORE to fill in those pointers with the addresses of these functions, when they get written.
Not necessarily. The "function2" in the example was not really known initially, it just that this quick example required a very simple data structure for storing function pointers - so it is just some reserved space, with known available offsets where you can put function pointers. If you wanted to make it some kind of struture with names and pointers, like hash table, it still would be possible with some complex combinations of LOAD and STORE directives - but not as easy as this simple example.
Post 17 Nov 2011, 08:25
View user's profile Send private message Visit poster's website Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
Tomasz Grysztar wrote:
Hugh Aguilar wrote:
What you are suggesting, seems to imply that we know ahead of time what functions we are going to write (FUNCTION1, FUNCTION2, etc.) and that we later use STORE to fill in those pointers with the addresses of these functions, when they get written.
Not necessarily. The "function2" in the example was not really known initially, it just that this quick example required a very simple data structure for storing function pointers - so it is just some reserved space, with known available offsets where you can put function pointers. If you wanted to make it some kind of struture with names and pointers, like hash table, it still would be possible with some complex combinations of LOAD and STORE directives - but not as easy as this simple example.


I don't really understand what you are suggesting. It doesn't really matter what data structure is used for my Forth's dictionary because FASM is still assembling at compile-time. I need to assemble new functions during the run-time of the program that I have already assembled. That is what I mean by "incremental assembly."

Normally in Forth, this is accomplished by writing an assemble in Forth that is available at run-time for the Forth program. That is most likely what I will end up doing. The downside is that this is a lot of work for me (you know better than most how much work is involved in writing an assembler), and it makes it difficult for me to link C libraries to the Forth program --- that is why I wanted to use FASM as my assembler, but to also use FASM at run-time within the Forth program that is written in FASM.
Post 18 Nov 2011, 05:34
View user's profile Send private message Send e-mail Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
Tomasz Grysztar wrote:
If you wanted to make it some kind of struture with names and pointers, like hash table, it still would be possible with some complex combinations of LOAD and STORE directives - but not as easy as this simple example.


I will most likely need to write a preprocessor to do this. In HLA I would have had their "CTL" (compile-time language), but in FASM I need to write my own.

Is it true that the caret ^ is not used anywhere in your assembler? If so, then I will use that to tag the lines that the preprocessor needs to pick out of the FASM source-code --- it will expand these macros into source-code that FASM can assemble.
Post 18 Nov 2011, 23:18
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
Hugh Aguilar wrote:
Tomasz Grysztar wrote:
If you wanted to make it some kind of struture with names and pointers, like hash table, it still would be possible with some complex combinations of LOAD and STORE directives - but not as easy as this simple example.


I will most likely need to write a preprocessor to do this. In HLA I would have had their "CTL" (compile-time language), but in FASM I need to write my own.
Well, some kind of "CTL" is an usual part for any assembler. fasm in fact has two - one is fasm's preprocessor (which is separate language processed before passing the source to parser/assembler), and fasm's multi-pass assembly-time language (which is the one that has LOAD and STORE directives among others). On this board you may find many examples of advanced applications of those layers, like compile-time RSA encryption, generation of TGA image or WAV sound file directly as assembly output or extraction of resources from PE file to include them in your own executable. Therefore I suggest that you should give fasm's "CTLs" a try before adding another layer on top of them.
Post 20 Nov 2011, 00:57
View user's profile Send private message Visit poster's website Reply with quote
Hugh Aguilar



Joined: 15 Nov 2011
Posts: 62
Location: Arizona
Hugh Aguilar
Tomasz Grysztar wrote:
I suggest that you should give fasm's "CTLs" a try before adding another layer on top of them.

Fair enough --- I'll learn more about FASM's macros before I consider writing my own preprocessor.

I'm actually writing two Forth systems. HostForth is written in x86 assembly for the desktop. TargForth is a cross-compiler written in HostForth --- it generates assembly code for the ARM and possibly some other micro-controllers.

I only need the incremental assembly for the ARM assembly language that is generated by TargForth. TargForth is really the interesting part of the project.

HostForth is just something that I have to get out of the way first, before I can start on TargForth. Lots of people have written x86 Forth systems and my HostForth won't be significantly different --- I want to slap together HostForth quickly, with as little work as possible --- I don't care about performance because it will run on the desktop computer not the micro-controller.
Post 20 Nov 2011, 05:52
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.