In MASM, if you define a symbol with the externdef directive, the
assembler won't link the file containing that external symbol unless you
actually reference it in your code. Similarly, Gas (which defaults all
undefined symbols to external) will not link in symbols you don't reference.
What is the behavior for FASM's EXTRN directive?
If I put an EXTRN directive in my code will FASM emit the external reference
to the OBJ file even if the code doesn't reference the symbol (beyond the EXTRN)?
Is there any equivalent of MASM's EXTERNDEF directive?

Randy Hyde
Posted on 2003-01-11 22:23:13 by rhyde

If I put an EXTRN directive in my code will FASM emit the external reference
to the OBJ file even if the code doesn't reference the symbol (beyond the EXTRN)?

Yes.
That's because fasm is very literal - whatever you put in source will be put into your output even in the same order. You can think of source code for fasm as of the "program" which tells assembler what to put in the output file.
Posted on 2003-01-12 03:28:32 by Tomasz Grysztar
The problem with this approach (extrn putting the link record in the object file)
is that it makes it very difficult to create generic header files for library modules
that are easy to maintain. Say what you will about C, but the semantics that
C uses for its extrn directive work out really well. This is what MASM attempted
to do by adding the externdef directive.

You should seriously consider adding a new form of the extrn directive that
has the following semantics:

1) If the EXTRN* definition is the only use of the symbol in the source file,
the assembler ignores it.

2) If the source file references a symbol defined by EXTRN* but does not
define the symbol, then the assembler emits an appropriate external
definition record to the emitted object file.

3) If the source file defines the symbol appearing in the EXTRN* directive
then the EXTRN* directive effectively defines the symbol as a PUBLIC
symbol, making it available to other object modules.

The traditional EXTRN/PUBLIC scheme is fine for stand-alone assembly
projects where all the source code for the project is written from scratch.
It runs into problems, however, when you attempt to maintain a set of
library routines (e.g., the UCR Standard Library for 80x86 Assembly
Language Programmers) where constant changes are being made to
the header files. Also, from an application programmer's point of view,
it's much nicer to include, say "windows.inc" and get all the constant,
variable, and procedure declarations in one shot (without having to worry
about linking unused code into your executable) rather than having to
manually pick out all the symbols you actually intend to use.

It took Microsoft until MASM v6.0 to figure this out.
MASM was quite a bit easier to use after they added this feature;
so I heartily recommend adding this feature to FASM.

Currently, I can deal with this problem in my compiler by doing the
grunt work in my code, but for programmers who are manually writing
multi-module code using libraries, having something like externdef
would be a godsend.
Randy Hyde
Posted on 2003-01-12 10:19:02 by rhyde
Oh, I see, you mean a GLOBAL directive. I thought about implementing it, maybe in next version.
Posted on 2003-01-12 11:49:48 by Tomasz Grysztar
BTW, you can implement such features on your own using macros. For example by using this macro you will put in object file only references to symbols you're actually using:


macro EXTRN symbol
{ if used symbol
extrn symbol
end if }

And here's the GLOBAL macro:


macro GLOBAL symbol
{ if defined symbol
public symbol
else if used symbol
extrn symbol
end if }

The only weak point of this macro is that "defined" operator checks whether the symbol was defined earlier in source, so you it'd be best to put all GLOBAL declaration at the end of the source file.
Posted on 2003-01-13 07:32:42 by Tomasz Grysztar

BTW, you can implement such features on your own using macros. For example by using this macro you will put in object file only references to symbols you're actually using:


macro EXTRN symbol
{ if used symbol
extrn symbol
end if }

And here's the GLOBAL macro:


macro GLOBAL symbol
{ if defined symbol
public symbol
else if used symbol
extrn symbol
end if }

The only weak point of this macro is that "defined" operator checks whether the symbol was defined earlier in source, so you it'd be best to put all GLOBAL declaration at the end of the source file.



Actually, this is exactly what I did in MASM prior to v6.0 appear (e.g., for the UCR
Standard Library for 80x86 Assembly Language programmers). Fortunately, for my
current needs, I can fix the issue on my end (i.e., scan through all my external
declarations and only emit those that the code actually references). That's probably
a better solution anyway, since it will make my compiler's output more general.
Randy Hyde
Posted on 2003-01-13 22:04:32 by rhyde
Does it mean you are trying to use FASM as a back-end to your compiler?
Posted on 2003-01-14 02:36:22 by Tomasz Grysztar
Yes,
I'm currently modifying HLA to emit FASM code.
I've got several requests for a version of HLA that emits
something other than MASM for use under Windows.
Though HLA can emit Gas, Gas code is off in its own little
world and the object files don't work well with other
Win32 tools. NASM has had a couple of show-stopper
problems (until recently it didn't support displacement
optimization and it doesn't do well with certain forward
references).

Now all I need is a decent MS-LINK replacement :-)
Randy Hyde
Posted on 2003-01-14 21:49:01 by rhyde

I'm currently modifying HLA to emit FASM code.

That's great! I like the idea of higher-level languages using fasm as their back-end; mainly just because I was writing first version of my assembler just for that purpose, but then happened that I just haven't got enough time/readiness to write also a HL compiler for it, improving the low-level features and optimization for fasm just took much more time that I initially thought. But this payoffs - now I can support other compiler programmers with the back-end assembler of good (and still getting better) quality. PureBasic has recently switched to fasm (and thery are happy with that, because they get better optimized code), and if HLA also has an option of generating code for fasm - I'm glad to hear that. Such events give me a hope that my 3.5 years of work won't be wasted.


Now all I need is a decent MS-LINK replacement :-)

Maybe you can try LCC linker (the one that PureBasic is currently using) - it's free.

Or maybe it's time for me to write some PE linker especially for fasm?
Posted on 2003-01-17 02:07:23 by Tomasz Grysztar
Writing a new linker would be a good thing. Especially if it were to be something about as flexible as the GNU linker... I really like the way it supports multiple input/output formats, and the very flexible linker scripts it has. But since it's GPL *u*x software, getting it to build "natively" on win32 is a major pita, and the internal architecture is atrocious (and doesn't seem to be properly documented), so I gave up adding my own input and output formats.

Sometimes, ms link just isn't flexible enough.
Posted on 2003-01-17 02:46:00 by f0dder
Privalov,

you wrote:

Or maybe it's time for me to write some PE linker especially for fasm?

This a very very good idea!:alright: With a PE linker for FASM, we can even make libraries!

:alright:

Regards,

Vortex
Posted on 2003-01-18 05:09:13 by Vortex
Anyone have any experience with ALINK?
Will it link FASM's COFF output?
Supposedly it works with MASM (PE/COFF) and
TASM (OMF). Don't know if it handles everything
FASM emits (or even if it handles everything MASM
emits, for that matter). It seems to be free and
source is available (I didn't bother reading up on the
license yet...)
Randy Hyde
Posted on 2003-01-20 23:18:35 by rhyde


Such events give me a hope that my 3.5 years of work won't be wasted.


A sentiment that I can relate to, entirely :-)
I can tell you, based on my past experience, tenacity is the key to making
a product like FASM successful. It took years for Webster to get to the
point where it was getting a million hits a year. Granted, having AoA
hosted on Webster helped, but a large part of Webster's success is that
it's been on-line more or less continuously since 1995 while a lot of other
sites have come and gone.

Fortunately, for the HLA->FASM conversion, I'd put in a lot of stuff to
support NASM before I figured out that NASM just wouldn't do the job
(at the time, things may have changed now, I don't know for sure).
Because of the preliminary work with NASM, FASM was definitely the
easiest port to date (of course, it helps to have dealt with all the generic
modifications that were necessary to support assemblers other than
MASM back when I did the first port to Gas).
I'm still tracking down bugs in the way I handle externals, but most
of the other stuff is working (of course, the real test will come when
I try to compile the HLA Standard Library).

Cheers,
Randy Hyde
P.S. I hope you'll be working on an AMD-64 extension before
too much longer.
Posted on 2003-01-20 23:27:56 by rhyde

Writing a new linker would be a good thing. Especially if it were to be something about as flexible as the GNU linker... I really like the way it supports multiple input/output formats, and the very flexible linker scripts it has. But since it's GPL *u*x software, getting it to build "natively" on win32 is a major pita, and the internal architecture is atrocious (and doesn't seem to be properly documented), so I gave up adding my own input and output formats.

Sometimes, ms link just isn't flexible enough.


Personally, I'd prefer a separate linker (executable) for each of the different
formats. It could be the same source file that compiles via conditional
compilation, but I don't feel there's a real need to carry around the ability
to link OMF or ELF in a program that's only going to be used under Windows
(and ditto for other OSes/environments). For those who'd like the "all-in-one"
approach, it's easy enough to write a little shell executable that processes
command line parameters and then runs the pertinent linker.
Randy Hyde
Posted on 2003-01-20 23:30:45 by rhyde

I hope you'll be working on an AMD-64 extension before too much longer.

That's a good point. I've started designing this extension a lot time ago, but it'll take also a lot of work to implement it, just because I'd have to change some deep architectural detail of fasm to support 64-bit addresses instead of 32-bit. But after that change, the rest will be simple - just replacing the "x86.inc" with "x86-64.inc" (of course, after making the second ;)). And then the last thing will be about the output formats.
Is there already a PE64 format version for AMD x86-64 designed? Does anybody have some info about it?
Posted on 2003-01-21 02:44:58 by Tomasz Grysztar
Randall, I think separate linkers would be wasteful, as there's very much duplicate code. Rather, having input/output format DLLs, or (what I prefer), build-time inclusion of the formats you want support for.
Posted on 2003-01-21 03:52:57 by f0dder
NAsm doesn't currently include an equalent for EXTERNDEF (MAsm) or GLOBAL (TAsm), either. It would certainly be nice to have it, gotta look at the source, how difficult would it be to implement.

-Stealth
Posted on 2003-01-23 09:05:56 by Stealth

Randall, I think separate linkers would be wasteful, as there's very much duplicate code.




Not at all! A new linker coded in asm could be very usefull.It could support alot the Flat Assembler.
It's very surprising for me to see that almost nobody is interested in using libraries with FASM.:confused:

Regards,

Vortex
Posted on 2003-01-23 10:23:24 by Vortex
i think you misunderstood me, vortex. I said that separate linkers
(ie, one for each output format) would be wasteful, not that having
a linker would be.
Posted on 2003-01-23 10:27:18 by f0dder
O.K. Sorry,f0dder:you are right!

Regards,

Vortex
Posted on 2003-01-23 10:28:48 by Vortex