flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > fasm as DLL

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
kalambong



Joined: 08 Nov 2008
Posts: 165

Tomasz Grysztar wrote:
Uploaded it now.




Thank you very much, Tomasz !! Laughing
Post 08 Apr 2012, 01:19
View user's profile Send private message Reply with quote
Aslan



Joined: 09 Sep 2013
Posts: 2
Post 09 Sep 2013, 19:04
View user's profile Send private message Reply with quote
DVicthor



Joined: 13 Sep 2013
Posts: 3
Location: Nigeria
Has anyone thought of making a pure or .pyd python wrapper around the FASM dll?
Post 16 Sep 2013, 16:13
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
two new functions for fasm dll interface
Hi all,

This is my first post, so I hope not to break some board stated, or not, rules. Moreover, I expect there is not a problem of replying to a thread that is inactive for so much time.

I have been fasming for two or three weeks now and I am liking it a lot (I have been fasming with fasm and I pretend to start doing it with fasmarm), so, first of all, I would like to thank the authors of both the projects, in special Thomas, which has been the initiator of all this.

I have not tested the fasm dll yet (it would be great if there was such a dll for fasmarm too!) because I would need two more functions for what I pretend to do:

fasm_Assemble(lpSource,lpMemory,cbMemorySize,nPassesLimit,hDisplayPipe,pToCallbackFunction)

and

fasm_AssembleFile(lpSourceFile,lpMemory,cbMemorySize,nPassesLimit,hDisplayPipe,pToCallbackFunction)

the argument pToCallbackFunction would be used by the fasm (or fasmarm) dll whenever a file would have to be opened (file directive or include directive), so that I could open it, preprocess it, and only then pass the data associated with it to the fasm (or fasmarm) dll in a memory block (this memory block should not be changed in any way by the dll, only read by it).

the callback should point to a function like:

requestToDllClientToOpenFile(lpSourceFileName,lpAsnwerStruct)

where the argument lpSourceFileName should point to a null terminated string with the name of the file to open (the name associated with this does not have to point to a real file if the client knows how to handle it) and the argument lpAnswerStruct should point to a struct in memory where the dll client would pass info to the fasm (or fasmarm) dll.

the info to pass to the fasm dll on this struct should be something like this:

uint32 success - this would inform the fasm dll whether or not the openning of the file was successfully. If an error occourred, then the fasm dll should stop fasming and report an error.

uint32 lengthInBytesOfPreprocessedOpenedFileData - this would inform the fasm dll (in case the file had been successfully opened) the length of the data associated with the openning request.

uint32* pToFirstByteOfPreprocessedOpennedFileData - this would point to the first byte of the data associated with the opening request (in case the file had been successfully opened).

Thomas, it would be really good if you could implement this!

Thanks in advance!

Best regards,

Ippasm
Post 24 Oct 2013, 11:50
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6435
Location: Kraków, Poland
This is a very good suggestion - it would allow to assemble multi-file projects completely in memory and it is actually something that I wanted to do.

I think I'd prefer to implement it with an additional function like "SetFileCallback", so that the fasm_Assemble function would be kept as is, completely backwards-compatible.
Post 24 Oct 2013, 13:01
View user's profile Send private message Visit poster's website Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
I am very happy you liked the idea!Very Happy

Yes, using such a function would be ok! I was assuming that the dll would be memoryless between calls to assemble, so I would never ask for such a function...

As you sugest such a behaviour (not memoryless) from the dll, another non-memoryless inclusion would be a function to handle some inc files before hand.

Specifically, imagine I have 100 inc files with macros and all the programs I want to assemble take profit of some of these macros, in this case it would be great if we could preload those macros just once and then we would only have to take care of the files of the specific programs afterwards.

Of course, if I only have a "wish", then forget the mention of this last function. Embarassed

Best regards,

ippasm
Post 24 Oct 2013, 13:07
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
Even if a function to preload macros would be great, if it will not exist, then the client of the dll can simulate it to some extent by preloading all his files with the shared macros to memory and when the fasm dll asks for them (indeed, for the file that contains them!) due to an include or file directive, then the client will just give the pointer to them and, with a bit of luck, they will not be paged out, so it will be quicker to pass that info to the dll than to access the disk each time such a file is requested by fasm.

Obviously, in this case, the client of the dll must maintain a data structure with the path in memory to the given files...

I am assuming that fasm does not "pre-compile" the macros and uses the files with the macros as an interpreter...

If it uses them as an interpreter and the client maintains these files in his memory, then satisfying an open request from fasm will be as quick as for fasm to maintain them internally in its memory and use them as required (the only difference in timming is a call to the client to pass the memory with the required file to the dll, instead of directly accessing its (fasm) memory where the files are maintained!).

By the contrary, if fasm does some kind of "pre-compilation" on the read files with the macros, then pre-loading them to the fasm dll will improve a lot the assembling, because this "pre-compilation", which surelly takes more time than passing memory around, would only be undertaken once.

Just some thoughts...

Best regards,

ippasm
Post 24 Oct 2013, 14:29
View user's profile Send private message Reply with quote
ippasm



Joined: 24 Oct 2013
Posts: 13
Hi all,

In my opinion there is one more plus to have the possibility of compiling multiple-file projects in memory: if the fasm dll does not access the file system, probably, it won't access any other file system call and, as so, we can use it in any other x86 OS (like android, linux, menuetos, etc) by undertaking the following steps:

1) open de dll file;
2) copy it to memory;
3) read the PE file data and find the code and data sections;
4) copy the data on the code section to a new location in memory and allow this memory to be read and executed;
5) copy the data on the data section to memory and allow this memory to be read and written;
6) find the pointer to the entry point of the dll and call it;
7) find the pointer to the function setfile callback and set the callback;
8) find the pointer to the fasm_Assemble function and start assembling the projects.....

Thomasz, if the client of the fasm dll undertakes all the 8 steps above, will he be capable of fasming projects in memory in non-windows oses, as expected?

I apologize for posing so many questions, but I am very excited with the possibility of fasming multiple-file projects in memory!

One last question, can we expect to have the said possibility soon (by the end of November, by the end of 2013, etc)?

Best regards,

ippasm
Post 25 Oct 2013, 10:23
View user's profile Send private message Reply with quote
Kenneth



Joined: 16 Nov 2005
Posts: 38
Location: United States of America
Trying to compile with most recent fasmw source cause an undefined symbol error for tagged_blocks. Commenting the offending line, the dll compiles fine.

Code:

cmp     eax,[tagged_blocks]
ja      out_of_memory



Is this check still necessary with most recent fasmw and what would be the equivalent? I don't have the old sources so I can't figure it out and it seems like it might be important.
Post 17 Nov 2013, 20:34
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Walter



Joined: 26 Jan 2013
Posts: 117
Kenneth,

Notice in the first thread of "fasm as DLL", it say
(assembled with 1.71.08 core).

My guess is that you are trying to assemble with fasm 1.70.03.

Use this version and you should be good:

http://flatassembler.net/fasmw17116.zip
Post 17 Nov 2013, 23:33
View user's profile Send private message Reply with quote
Kenneth



Joined: 16 Nov 2005
Posts: 38
Location: United States of America
I never notice there were newer fasm releases available on the downloads page, thanks.
Post 18 Nov 2013, 00:16
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
theBB



Joined: 24 Jul 2014
Posts: 1
Hi everyone, this was asked before but i think it hasn't been answered yet.

I would like to use FASM as .so in linux. How can i create .so version of FASM or do you have .so version of it?
Post 24 Jul 2014, 06:22
View user's profile Send private message Reply with quote
evk1



Joined: 18 Jun 2014
Posts: 23

theBB wrote:
Hi everyone, this was asked before but i think it hasn't been answered yet.

I would like to use FASM as .so in linux. How can i create .so version of FASM or do you have .so version of it?


ELF DSO usually use position-independent code, FASM uses absolute addresses for global variables, so I think it is hard to port FASM library to Linux without source code rewriting.

_________________
Sorry for my English
Post 24 Jul 2014, 14:43
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow

rugxulo wrote:
Nifty. This makes me want a QBASIC-like IDE where you can run immediate assembly code. (To be honest, I'd never use it, but it'd be cool.)

P.S. Any reason for including FASM.DLL in the .ZIP twice? (seems silly but maybe I'm overlooking something).



Scheme! Smile

http://en.wikipedia.org/wiki/Scheme_%28programming_language%29
Post 05 Dec 2014, 22:23
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.