console program

[Hugh Aguilar]

Is there a library available that will allow me to write console programs in NASM that will assemble under either Linux or Windows without changing the source-code of my program but just by setting a directive? I know that HLA has a library like this, but wondered if anything was available for NASM. Is there a repository of publicly available NASM code somewhere that would have libraries such as this?

I tried to get on the NASM mailing list and I posted the above question there, but it never showed up. I've never received any emails from that mailing list. Did the moderators block my question and/or ban me from the mailing list? Is there any way for me to find out my status?

Also, btw, is there a version of NASM retargeted for the ARM?

Does NASM support incremental assembly? I already asked this question on comp.lang.asm.x86 and was told "no," but I though I would ask it here as well.
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e54f416e32cd1a75

[Rob Neff]

Shameless plug: Although not a library of routines you can easily build cross-platform programs using NASMX.  The package was designed for exactly this purpose.  It is not a panacea or silver-bullet as you'll have dependencies if you target OS specific capabilities.  You will find a wealth of examples there that demonstrate what NASMX is capable of. 

Nasm is Intel specific and does not target ARM.

Nasm does not have incremental assembly.  I personally would love precompiled includes but alas that's not available either.

[Keith Kanios]

Does NASM support incremental assembly? I already asked this question on comp.lang.asm.x86 and was told "no," but I though I would ask it here as well.
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e54f416e32cd1a75

By your definition at CLAX, linking modular objects into a binary would be the most logical/standard way to achieve this.

Linkers have an advantage in that they don't have to go through the entire parsing and code generation phase, i.e. it should be faster.

You could probably use NASM's preprocessor as a "linker" of sorts, but that would quickly become convoluted without a solid design plan. I would recommend just assembling to RDOFF2 (-f rdf) and using the RDOFF tools (part of the NASM source) to link everything into a solid binary. Read up on RDF/RDOFF/RDOFF2 in the NASM Documentation for some ideas on how to achieve this.

[Frank Kotler]

Is there a library available that will allow me to write console programs in NASM that will assemble under either Linux or Windows without changing the source-code of my program but just by setting a directive?

Sure - C. In 32-bit code, this isn't much of a problem. You'd have to change "main" (Linux) to "_main" (Windows) - Nasm has a command-line option which will do this. Also "strncasecmp" to "strnicmp" - probably a few others. In 64-bit code, there's a completely different ABI. The NASMX macros will go a long way towards smoothing out these differences.

I know that HLA has a library like this, but wondered if anything was available for NASM.

Strictly speaking, HLA has two libraries (maybe 3). You can call the HLA library from Nasm code - requires some "extra" code to meet the expectations of HLA (structured exception handling). HLA generates this code "behind your back". I've managed to do this - not in a very "portable" way, and not recently. I don't know if it will still work or not. I don't see much point in this - the C library is more widely ported, more extensive, and more thoroughly tested...

Is there a repository of publicly available NASM code somewhere that would have libraries such as this?

The NASMX package is probably the closest thing to this, although it isn't strictly speaking a library. It's a set of macros and include files which will allow you to write portable code - between Linux and Windows and even between 32- and 64-bits.

I tried to get on the NASM mailing list and I posted the above question there, but it never showed up. I've never received any emails from that mailing list. Did the moderators block my question and/or ban me from the mailing list? Is there any way for me to find out my status?

That's my fault. Sorry, Hugh! Mail is being sent to an account I can't currently log into. There has been so little traffic on that list lately that I haven't been concerned about it. I'll see if I can get it straightened out...

Also, btw, is there a version of NASM retargeted for the ARM?

There's a project on SourceForge called "Narm". I don't know if it's in useable shape or not. I haven't heard anything about it... so probably not.

Does NASM support incremental assembly? I already asked this question on comp.lang.asm.x86 and was told "no," but I though I would ask it here as well.
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e54f416e32cd1a75

Sorry, I kinda dropped the ball on our conversation there. A snowstorm took the power out for several days, and when I got back on line, things had moved on. You gave an example something like this:

Code: [Select]

code flag ( n -- flag )  ok
    ebx ebx or  0<> if  -1 # ebx mov  then  ok
    ret  end-code  ok
9 flag . -1  ok
0 flag . 0  ok
see flag
46E89F   EBX EBX OR                     09DB
46E8A1   46E8A8 JZ                      7405
46E8A3   -1 # EBX MOV                   BBFFFFFFFF
46E8A8   RET                            C3 ok

Seems to me you'd need an editor (and a disassembler) integrated with your assembler to get a result like this. Nasm would assemble a "partial" file - provided that all the symbols were defined... which they normally wouldn't be. If we define "increment" to be something like...

Code: [Select]

    ebx ebx or  0<> if  -1 # ebx mov  then  ok

... where the "target" of the jump is known, so the number 5 could be plugged in, Nasm would assemble the resulting few lines of code as an "increment", but the few lines of code would have to be generated first. I don't know if this would be practical in the general case. It would be a function of your compiler, not something Nasm knows how to do. So I'd still have to say "no", although perhaps Nasm could be integrated into an editor/compiler/assembler(Nasm) that would do something like that.

I'll see if I can get back to our discussion on c.l.a.x. - there are some aspects of RosAsm that might interest you, in spite of it being "dead" for all practical purposes...

Best,
Frank

[Hugh Aguilar]

Shameless plug: Although not a library of routines you can easily build cross-platform programs using NASMX.  The package was designed for exactly this purpose.  It is not a panacea or silver-bullet as you'll have dependencies if you target OS specific capabilities.  You will find a wealth of examples there that demonstrate what NASMX is capable of. 

Nasm is Intel specific and does not target ARM.

Nasm does not have incremental assembly.  I personally would love precompiled includes but alas that's not available either.

I am actually writing *two* Forth compilers. HostForth will be written in x86 assembly language (possibly NASM) and will be a traditional Forth pretty much the same as dozens of other people have written --- except that it will have features that make it useful for being used as the basis for a cross-compiler. The reason why I'm not using Gforth is because Gforth lacks these features, and will never get these features --- mostly features for manipulating word-lists.

TargForth will be written in HostForth and will be a cross-compiler. It will generate code for various processors --- mostly micro-conrollers such as the ARM.

The assembler used to write HostForth doesn't necessarily have to be the same assembler that TargForth generates code for. I have already started writing HostForth in HLA, but HLA is somewhat of an overkill as I don't really need all of that high-level language stuff (because HostForth is a high-level language itself). For simplicity, I may switch over to NASM. I have yet to get on the HLA mailing list, which is making me want to drop HLA and switch over to an assembler with a friendlier community. This program does need to have console I/O so I can have a typical Forth environment. It also will need serial com code for communicating with the micro-controller. All of this is pretty basic; I'm not doing anything fancy with either the console or the serial stuff.

The incremental assembly is needed for the assembler that TargForth generates code for. The usual way to do this, is to write the assembler in Forth. I've done this myself in the past. This is a lot of work though. Also, it doesn't allow me to link Forth code together with C libraries. Because of this, I want to use a mainstream assembler such as GAS or whatever, but I also want to upgrade that assembler to support incremental assembly so that I can have the usual Forth interactive development --- the user can write a function in Forth and/or assembly code and that function will be immediately available for testing --- and the existing data generated by the program doesn't get clobbered, so it can be used for testing the new function.

I'm mostly interested in targeting the ARM because it is the most popular micro-controller these days, but I would also like to support other micro-controllers as well, such as the PIC24, the PIC32 (this is actually the MIPS), and the MSP430. Because of this, I am mostly thinking of TargForth generating GAS because GAS has versions available for a wide variety of processors. I should be able to generate code for any processor that has at least 16 general-purpose registers --- humorously, that means that I can generate code for the MSP430 but not the 32-bit x86 --- but that is okay, because the 32-bit x86 isn't a micro-controller anyway, so I don't care about it.