flat assembler
Message board for the users of flat assembler.
Index
> Main > FASM for use in Forth cross-compiling |
Author |
|
Hugh Aguilar 16 Nov 2011, 05:56
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. |
|||
16 Nov 2011, 05:56 |
|
Hugh Aguilar 16 Nov 2011, 09:14
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. |
|||
16 Nov 2011, 09:14 |
|
revolution 16 Nov 2011, 09:22
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. |
|||
16 Nov 2011, 09:22 |
|
AsmGuru62 16 Nov 2011, 15:09
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. |
|||
16 Nov 2011, 15:09 |
|
Tomasz Grysztar 16 Nov 2011, 19:02
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 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 |
|||
16 Nov 2011, 19:02 |
|
Hugh Aguilar 17 Nov 2011, 04:07
AsmGuru62 wrote: FASM is very fast assembler, so I do not see the need for incremental feature. 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. |
|||
17 Nov 2011, 04:07 |
|
Hugh Aguilar 17 Nov 2011, 05:01
Tomasz Grysztar wrote: Interesting. I once saw someone using fasm in a way that resembles this a bit. 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. |
|||
17 Nov 2011, 05:01 |
|
Tomasz Grysztar 17 Nov 2011, 08:25
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. |
|||
17 Nov 2011, 08:25 |
|
Hugh Aguilar 18 Nov 2011, 05:34
Tomasz Grysztar wrote:
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. |
|||
18 Nov 2011, 05:34 |
|
Hugh Aguilar 18 Nov 2011, 23:18
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. |
|||
18 Nov 2011, 23:18 |
|
Tomasz Grysztar 20 Nov 2011, 00:57
Hugh Aguilar wrote:
|
|||
20 Nov 2011, 00:57 |
|
Hugh Aguilar 20 Nov 2011, 05:52
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. |
|||
20 Nov 2011, 05:52 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.