Author Topic: nasm.dll ?  (Read 16498 times)

nobody

  • Guest
nasm.dll ?
« on: May 24, 2005, 01:20:38 AM »
Hello im writing a dll whitch contais nasm compiler i will use it as a back end to my compiler of course i will make it GNU open source but can i still make the dll ? who i've to tak whit ?
regards benjaminmaggi@yahoo.com.ar

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: nasm.dll ?
« Reply #1 on: May 24, 2005, 03:25:29 AM »
Hi Benjamin,

You don't need "permission" from anybody, as long as you follow the provisions of the license. Nasm is under LGPL, the "lesser" or "library" GPL - as a .dll, the "library" license might actually make *sense*!

According to "internal.doc", Nasm was *intended* to be used in just such a manner. I seem to recall hearing that the "interface" (between modules, not the user interface) wasn't really quite right to do it, though... It will be interesting to see what, if any, problems you run into...

You might want to post your ideas to the "nasm-devel" list (the "lists" link, above), to see if anyone has any advice or suggestions for you. Someone *may* have done (or tried) this before - although I'm not aware of it.

But the license itself gives you all the "permission" you need. Go for it!!!

Best,
Frank

nasm64developer

  • Guest
Re: nasm.dll ?
« Reply #2 on: May 26, 2005, 05:58:13 AM »
> Someone *may* have done (or tried) this
> before - although I'm not aware of it.

I have successfully tried several variants
before: pass in an input file name and then
process the file as usual, pass in a chain
of strings and process them as if they came
from an input file, pass in a line and let
it be preprocessed and/or assembled, etc.

In general, NASM's overall structure is not
too bad. However, NASM 0.98.xx still suffers
from a number of memory leaks, as well as a
number of bugs which can lead to core dumps.

Though I tried to file SF bugs whenever I've
fixed one of those issues during my work on
NASM64, I might not have been 100% diligent.

Fwiw, one key question is whether you plan
to process input on a line-by-line basis or
on a per-file basis. If you preprocess and
then assemble each line, then you will be
able to access previously defined labels in
the preprocessor. By contrast, if you feed
the whole input through the preprocessor and
then through the assembler, then the former
will not be able to access previous labels.

nasm64developer

  • Guest
Re: nasm.dll ?
« Reply #3 on: May 26, 2005, 06:03:41 AM »
Have you considered to make your compiler
emit assembly code files? (IMO that path
offers greater flexibility, and it avoids
the need for creating/maintaining a .dll
with wrapper code. Oh, and the compiler
could emit different flavors of assembly
so that you could use it with NASM, MASM,
TASM, GAS, etc. as a backend. ;-)