I cannot link the 32-bit fasm object module because
I am running 64-bit OpenBSD. Is there a 64-bit
fasm object module available for me to link with?

Sorry no 64bit version of fasm.

For the *BSDs, you need to install the base 32bit libraries (available through the ports/packages) and enable use of 32bit executables, and then manually link the 32bit fasm.o to the base libraries... (There are a few posts in here related to FreeBSD and the same problem).

To manually link on FreeBSD 6.1 AMD64 I use:



then copy "fasm" to /usr/local/bin

Hope this helps

Unfortunately, there is no 32-bit execution mode in 64-bit OpenBSD.
Similarly, there is no 64-bit execution mode in 32-bit OpenBSD.
(There also is no 64-bit Linux emulation mode)
But I am making progress in assembling a 64-bit version of fasm using
yasm. I am using Phil Budne's CSnobol4 (also running in 64-bit mode)
to automate the conversion of fasm syntax to yasm syntax for the port.
The conversion so far is pretty straight forward.

dfeustel, but be carefull about the conversion. fasm uses 32-bit pointers so OpenBSD should always assign memory on addresses below to 2^32 to work properly (or this converting utility must have some magic feature to detect memory references and change the instructions to use 64-bit registers).

To be honest, I didn't realise that. Sorry. Seems rather strange though. I guess the OpenBSD developers have their reasons.

As LocoDelAssembly mentioned, be very careful with conversion utilities...

Not to start a flame war or anything, any reason why OpenBSD over FreeBSD? If you're stuck on OpenBSD, then NASM (the latest beta's) and YASM (or gas) are your only real choices... (Even though I wish you luck with converting fasm to be 64bit).

Any joy here?

I have never used a 64 bit processor...

But does any one know if it is possible to run WINDOWS or LINUX with a 64 bit processor, without compiling the source, JUST interpreting the whole source code?

IF 64 bit processors are not fast enough, we will need to wait 128 bits processors, or even 256 bits processors.

This step if having a compiled version of windows sucks... same, having to use a compiled version of linux sucks too... how long now to wait until the compilation becomes totaly optionnal, so we can have windows and linux with the sources being interpreted in a debugging window .

fasm works under Linux or Windows 32 emulation in Bochs and QEMU. If DosBox would support unrealmode, it would be more practical though. Where's the FASM lobby?
However fasm speed would be severely affected in those conditions.

Oh, FASM actually works undes DosBox. You just need to use a 32-bit DPMI extender from FreeDOS, for example. It takes 1.8 seconds to assemble itself in my Pentium 4. If you don't care about assembler speed it will do its job. And using DosBox you can access your generated binary directly from the 64-bit host OS.

DOSBox relies on 33 external libraries (Linux version?), so they refuse to build statically (I asked!). Lots of Linux distros don't update DOSBox, so you're stuck with old, old versions (very annoying). Anyways, you could always use "STUBIT" (from WDOSX) to make an all-in-one Win32 FASM.EXE (cmdline version). It (modified Win32 .EXE) seems to reassemble itself okay here (DOSBox 0.72, Pentium 4, 1.6 secs.) without needing external DPMI servers although normal WinXP seems to not like running it:

FATAL: Could not allocate 00000000 bytes local application heap!

Just FYI. :-/

Why can't one of you brain surgeons just port fasm to x64?