Hi guys. I know Frank hangs out here so I will say right up front I love NASM and the NASM guys and my question is not about not using NASM. Ok!

I never used MASM and I am coding on Linux 32 bit for now. I prefer to work from listings instead of source and I saw JWasm has a more extensive listing than other Intel assemblers I have found. But I don't know MASM syntax and I don't know how to convert a simple NASM program to JWasm. The sample code on the JWasm site for Linux didn't help me because I have global and extern and I don't see them used in those samples. I did get my macros and structs converted but I didn't see how to create instances of a structure but I will keep going over the old MASM 6.1 doc and try to figure that out.

Is there any discussion or doc/examples on the topic of converting NASM to JWasm or more comprehensive JWasm examples for Linux so I can see where I am going wrong?
Posted on 2011-07-13 05:06:03 by JoeCoder
Hi Joe,

No replies, eh? Why don't you show us what you've tried, and what Jwasm has to say about it, and that may enable Masm users to help? My experience has mostly been Masm->Nasm, and mostly long ago, but maybe I can "reverse the process"...

Of what you mention, "global"->"public", and "extern" may be spelled "extrn". I imagine they're used the same way - "public" for something that exists in this file, and needs to be made known to the linker, and "extrn"(?) for something that's used in this file, and we need the linker to go find it for us.

I don't recall the syntax for defining a structure, but if you've got that, I believe we initialize a structure with a comma delimited list of numbers (symbols/expressions) between angle brackets, something like...


my_instance my_structure <1, 3, 5, offset my_func, foo+bar>


Might need to reverse "instance" name and structure name. See which one Jwasm doesn't barf on.

I think the most trouble I'd have is figuring out where to put "offset" and where not. Remember in Nasm syntax, just "myvar" is the address/offset, and "" is the contents. In Jwasm syntax, you need "offset", the unadorned "myvar" means contents! (if it's a variable - otherwise sometimes not!) Leaving the square brackets in from your Nasm code shouldn't hurt, even where Jwasm doesn't need 'em. You may need a "byte(word/dword) ptr" in some places. Since Jwasm "remembers" that you said "myvar" was db/dw/dd, where Nasm doesn't, I think you can get away without many "dword ptr"s. Masm programmers used to use a lot of 'em, and seemed to prefer uppercase, but I think Jwasm can hear you without having to "shout". :)

Something I noticed with (some versions) of Masm...


mov cl, byte ptr [81h]


insisted on generating the "immediate":


mov cl, 81h


The trick was:


mov cl, ds:[81h]


The "ds" prefix doesn't appear in the code, but is/was apparently a necessary part of the syntax. If you told Nasm, "ds" (would have to be inside the square brackets), you'd get the (probably redundant) "ds" prefix! I doubt if you'll run into that one.

That's about all I can think of... try posting examples (Nasm syntax or even pseudocode) of what you're trying to do, and what Jwasm thinks of 'em. I'll bet if you could come up with a decently-commented example for Linux, fairly simple, but using macros and/or structures, Japheth might include it in his package. I'm guessing he'd welcome more examples.

(for those who don't know Joe, he's a "newbie" to x86 and our quaint operating systems, but has considerable experience on others, so you don't have to be too "gentle" on him)

Best,
Frank

Posted on 2011-07-15 23:43:45 by fbkotler
JWASM has some problems in its ELF backend which make it not viable as a crossplatform option - see NASMX !!!
To qualify that - I notified Japheth a couple of years ago about this and he has done nothing about it... in fact at the time he suggested that until he was hassled enough it was not a priority - evidently so.
Posted on 2011-07-17 09:30:09 by Homer
What issues are you having with Jwasm's ELF back end, Homer? I've used it very little (as you know, I'm a "devout Nasmist") but it "seemed to work"...

Looking at it from the other end, what do you like about Jwasm's "listings" that you don't get from Nasm, Joe?

There must be some way to work this out...

Best,
Frank

Posted on 2011-07-17 12:30:50 by fbkotler

What issues are you having with Jwasm's ELF back end, Homer?


Generally broken, as I reported quite some time ago.
Posted on 2011-07-17 13:00:51 by SpooK
I see mostly "Wikipedia wars" there. Are you speaking of the fact that Jwasm's ELF output won't convert to Mach-o? Could be true - I'm not able to test MacOS, nor 64-bit output. Seems a little unfair to say that an assembler is "broken" without saying what's wrong with it. I may have to obtain the latest version and cook up some examples to try (painful, as I personally consider the syntax "horrid", but some people like it). It would be easier if I knew what I was lookin' for...

Best,
Frank

Posted on 2011-07-17 13:40:39 by fbkotler

Are you speaking of the fact that Jwasm's ELF output won't convert to Mach-o? Could be true - I'm not able to test MacOS, nor 64-bit output. Seems a little unfair to say that an assembler is "broken" without saying what's wrong with it.


I do note that it seemingly works fine under Windows.

OBJCONV is fairly robust... there has to be something pretty jacked-up for it to fail on conversion of a simple "Hello, World!" app.

In shorter words, it is broken... as far as cross-platform support is concerned. With respect to what Homer said, it sounds like that is still the case.


I may have to obtain the latest version and cook up some examples to try (painful, as I personally consider the syntax "horrid", but some people like it). It would be easier if I knew what I was lookin' for...


Yes, please do independent review... perhaps you can find the root of the cause and suggest a patch/fix!
Posted on 2011-07-17 14:34:47 by SpooK
Okay. Unlikely I'll be able to create a patch, but maybe can narrow down where to look. I visited the JWasm board at SF (it butchered my post, as usual) and put in a link back to here asking for help, and grabbed the latest version while I was there. Haven't tried to build/install it yet.

While I am highly impressed with "objcopy", it doesn't like some of "my" files either, so I might not consider that a show-stopper. I'll see what I see, if/when I get around to it...

Best,
Frank

Posted on 2011-07-17 15:46:01 by fbkotler

Okay. Unlikely I'll be able to create a patch, but maybe can narrow down where to look.


-JWasm Windows Binary: ELF works fine
-JWasm Windows from Source via OW19: ELF works fine
-JWasm Windows from Source via PellesC: ELF works fine
-JWasm Windows from Source via MinGW (GCC 3.4.5): ELF works fine
-JWasm Linux Binary: ELF works fine
-JWasm Linux from Source via OW20b: ELF works fine
-JWasm Linux from Source via GCC (4.5.2): ELF is broken
-JWasm Mac from Source via XCode (GCC 4.2.1): ELF is broken

Looks like the use of GCC to build JWasm is the root of the issues I have experienced.

The example I've used is quite simple, just syscall/print and syscall/exit, so saying "ELF works fine" above is only relevant in that context.
Posted on 2011-07-17 20:02:05 by SpooK
Wow, you've done some research on this thing!

As a WAG, without even looking at the code: uninitialized variables. We ran into something similar with Nasm, some time back - Chuck's build worked, mine did not (bogus addresses, IIRC). Initializing some variables fixed it.

Compiling JWasm 2.06 with gcc (linux) 4.2.1, gcc produced only one warning. Adding the "-Wall" switch in the makefile generated a whole pantload of 'em - "err.log" runs almost 460k! No way I'm going to try to fix all that!

The resulting jwasm seemed to "work okay"... but I couldn't get it to emit any listing file at all! Jwasm didn't complain about "-Fl=linux2.lst", but didn't create the file. Adding various "-S" switches didn't help.

I stand corrected. You guys are right, JWasm is not currently suitable for cross-platform work. Joe, maybe try Yasm and see if you like its list file better.

Sorry I mentioned it.

Best,
Frank

Posted on 2011-07-18 01:15:49 by fbkotler

Hi Joe,

No replies, eh? Why don't you show us what you've tried, and what Jwasm has to say about it, and that may enable Masm users to help? My experience has mostly been Masm->Nasm, and mostly long ago, but maybe I can "reverse the process"..."


Hi Frank,

Sorry I didn't come back to this very fast, I was on the road for a few days and was pretty busy. Actually I am getting over the humps one by one when I have a few minutes to work on it. I believe I have the structure stuff converted over (minimal, once you know how!). My main areas in my small example are I don't know they do .bss (obviously not critical but nice to have) and the instruction syntax is different so stuff like mov byte or mov word gives me error messages. I'm sure I'll figure it out if I spend enough time on it. The NASM 6.1 programmer's manual and reference do help but some JWasm specific doc would have been even better. I didn't "resolve" (hah, pun intended) the extern and global issues but I can probably get it from the doc when I pay attention. Thanks for all your comments and help, as usual!


That's about all I can think of... try posting examples (Nasm syntax or even pseudocode) of what you're trying to do, and what Jwasm thinks of 'em. I'll bet if you could come up with a decently-commented example for Linux, fairly simple, but using macros and/or structures, Japheth might include it in his package. I'm guessing he'd welcome more examples.


I have a hard time believing anything I do on x86 is going to be "example worthy" for another decade or so but a conversion guide would be helpful. You know alot of these projects are more about letting people who were already using/liking something (Watcom assembler in this case) continue using it on Windows/Linux etc more than they are about advocating so the people who already used it know what to do. Anybody coming to it new who didn't use MASM will find NASM, FASM, etc easier because of the great support and doc. JWasm seems to be relying on MASM doc which might be ok on Windows but isn't exactly relevant on Linux.
Posted on 2011-07-18 05:44:37 by JoeCoder
Thanks Homer and Spook for the help, nice to meet you guys. I am not interested in "cross platform" as in wanting to be able to use the same source on more than one platform (I'm not against it of course but have no particular need for it) but if "cross platform" means JWasm doesn't work except on Windows then "Houston, we have a problem!"  I'll take Frank's advice and look at YASM. I didn't think it would be any different from NASM as far as the listings go. I'm satisifed NASM seems to be the best general purpose multiplatform x86 assembler according to what I've read, and the support can't be beat and the doc is quite good. I like FASM because it's so fast and written in assembly. That makes you go "yeah!" when you realize it. The support is also great, there are a few guys who have been around along time and know how to get stuff working with FASM. The only thing "lacking" is just from my point of view since I work from listings and rely on them heavily but from what I have seen people on Intel are working almost exclusively from source and disassembly.
Posted on 2011-07-18 05:52:15 by JoeCoder

Thanks Homer and Spook for the help, nice to meet you guys.


You know me from the NASM forum by my real name ;)


I am not interested in "cross platform" as in wanting to be able to use the same source on more than one platform (I'm not against it of course but have no particular need for it) but if "cross platform" means JWasm doesn't work except on Windows then "Houston, we have a problem!"


If you continue to use the precompiled JWasm binaries, you should be mostly OK.
Posted on 2011-07-18 08:56:24 by SpooK

As a WAG, without even looking at the code: uninitialized variables.


That would be my initial assumption as well, as comparisons of the object dumps suggest a lot of garbled/junk data is being after/between relevant portions of the ELF structure(s) when using the GCC compiled version.
Posted on 2011-07-18 22:15:01 by SpooK

You know me from the NASM forum by my real name ;)


Well then Hello! Whoever you are ;-)

and thanks for the help!
Posted on 2011-07-28 05:05:41 by JoeCoder
I haven't talked to Japheth in a fairly long time, and to be honest I can't exactly remember what it was that is messed up with the ELF output format. I vaguely remember it having to do with his "minimal implementation" of the ELF format and creation of archive files. This was brought up when I was trying to help Homer & Biterider port OA32 to JWASM/Linux. However, this has really been a few years ago and I've noticed JWASM does support a lot more (from the demos) since then, so Japheth may have already fixed it. I'll download a copy later and see if I can't try a few build tests to see if I can refresh myself on what limitations (if any) it has.

Frank:
Btw, you're probably more likely to get a response from Japheth if you send him an email (should be available on his site). He was always really prompt when I emailed him.
Posted on 2011-07-29 23:28:00 by Synfire
Hi Bryant,

Actually, JWasm works fine for me on Linux, except that I can't get a "list" file out of it (which was Joe's entire purpose for trying JWasm, as I understand it). Apparently "some" builds of JWasm compiled with "some" versions of GCC give screwed up ELF output. The "workaround" is just don't use those builds! OpenWatcom C will probably compile a working version - haven't tried it...

A higher priority for me is to get back to that "libxcb" issue that you tried to help me with! :)

Best,
Frank

Posted on 2011-07-30 08:25:52 by fbkotler