OS X 68k assembler

[~llama]

...I've been trying to find one for a couple of days. Does anyone know of a good one, or a cross-platform one that will probably build on OS X?

 

Thanks

[Bruce Tomlin]

I'm pretty sure the old MPW environment was made freely available by Apple quite a few years ago. But if you can find it, you will have to run it under Classic.

[+batari]

...I've been trying to find one for a couple of days. Does anyone know of a good one, or a cross-platform one that will probably build on OS X?

 

Thanks

If you are brave, you can try to build m68k binutils in OS X, then just use the GNU assembler (as) to assemble your code.

[Tom]

Was going to suggest the same, but why do you think this needs any bravery ?

[+batari]

Was going to suggest the same, but why do you think this needs any bravery ?

The last time I tried to build a cross-compiler, it took me about 18 hours to get it working. Come to think of it, just building binutils wasn't that bad, it was getting the actual cross-compiler going that was tough.

[Tom]

That's why I was asking. Binutils is no problem. Getting Binutils, GCC and a C Library to work however is a bit harder. And it gets really fun if you want your toolchain to compile C++ programs.

 

Although I haven't used gas for writing 68k code I can only recommend it (except for writing x86 code. NASM is better for that).

[~llama]

Hmm... I think I'll try to go with MPW--having to use gas syntax doesn't sound fun, I've tried it on x86. I was sort of hoping there was a DASM-like or something for OS X that I didn't know about and couldn't find with Google. Bruce, how hard would it be for me to hack 68k support onto your assembler? I've been digging through the source--is it pretty much 8-bits only?

 

Worst-case, would there be any interest in a stand-alone 680x0 assembler for OS X with DASM-ish capabilities?

Edited April 22, 2006 by ~llama

[Tom]

I've tried it on x86

 

That's where gas sucks at for several reasons (stupid non-standard AT&T syntax, limited real mode support, ...).

 

I've written quite a bit of ARM (ARM and Thumb) code with gas, both as inline assembly with gcc and standalone, and it's great. Seriously, before you go and write your own 68k assembler, try out gas and other available assemblers (don't know any from the top of my head that might be worth looking at).

[Bruce Tomlin]

Bruce, how hard would it be for me to hack 68k support onto your assembler? I've been digging through the source--is it pretty much 8-bits only?

Ha ha ha. I was just thinking about it again the other day. It really isn't designed for anything beyond an 8-bit CPU. And I would like to have one someday, too. Why do you think I mentioned MPW?

 

Here's some links you might want to check out:

 

http://www.lightsoft.co.uk/Fantasm/fant.html - hmm, I just downloaded that and not only is it a "real" dev system which requires a link step to get binaries... the 68K assembler is written in 68K assembler! I thought people stopped writing big things like that in assembler back in 1989 or so. Sheesh.

 

http://home-1.tiscali.nl/~solognt/ - another 68K assembler written in 68K assembler. But it was for the Amiga, so it should be old enough to forgive for that.

 

hmm... maye I should check the comp.sys.m68k FAQ? "as68K"... wow, that was easy to find references, hard to find a download...

 

http://www.lysator.liu.se/~celeborn/sync/atari/misc.html

 

...except it needs a bit of work to get it to compile. The first thing is to lowercase the names of all the .C, .H, and .S files, and the makefile. Wow, this thing is pre-ANSI and actually uses "const" as a variable name! It's got other problems, too. I'll see if I can whip it into shape this morning.

[Bruce Tomlin]

Duh. Stupid CRLF newlines were causing the awk script to emit strings with return characters inside. (that in addition to using "const" as a variable name and uppercased file names)

 

Here's the source code, just needs a "make" command to build it: as68k.zip

And here's a pre-built binary that should run under 10.4: asm20.zip

Edited April 22, 2006 by Bruce Tomlin

[+batari]

I've tried it on x86

 

That's where gas sucks at for several reasons (stupid non-standard AT&T syntax, limited real mode support, ...).

 

I've written quite a bit of ARM (ARM and Thumb) code with gas, both as inline assembly with gcc and standalone, and it's great. Seriously, before you go and write your own 68k assembler, try out gas and other available assemblers (don't know any from the top of my head that might be worth looking at).

Yeah, I've also written ARM code using gas, after switching over from Codewarrior. The syntax is very similar. I ported some old code over in a relatively short time, IIRC, by just changing the comment character from ; to @, changing a few labels and some modifications to the way gas handles the literal pools. For the most part, I didn't need to change the actual instructions at all.

 

The syntax may be similar for other platforms too. m68k-gas may even support multiple syntaxes through an assembler directive or something. (I've been told that some later versions of ARM-gas do, but I haven't figured out how.)

 

Personally, I'd second trying out gas, as it's probably going to have better support these days.

[~llama]

asm20 built on the first try. I'm going to try using this and gas both for a while and see which one I prefer... although rolling my own does sound like it'd be kinda fun

 

EDIT: I've been trying forever to get binutils to compile for m68k and it just doesn't want to happen. I'm currently using asm20, which is okay I guess. It compiles most of the old ST source code (mainly "Fusion Forth 68k," for a homebrew 68000* project :-P) I've been using for testing purposes...

 

Is there any interest in a new assembler? or is gas enough for everybody else? I may end up rolling my own with really nice macros anyway, or figuring out how to use M4 with asm20.

 

* As in computer, not game.

Edited April 23, 2006 by ~llama

[Wrathchild]

How about the Sozobon toolkit?

 

A year or two ago I took the version 2 sources and

got these to compile on cygwin (using gcc) so that

those tools were then able to build the Atari binaries.

 

I tested both sets by building one of the z-code interpreters,

which helped iron out some endian issues.

 

I could post up sources if required.

 

Regards,

Mark

[~llama]

Well, just an update: I've been trying to get Fantasm and LIDE running, but it's asking me for a serial number, even though the app is free now... Is there a serial number anywhere?

 

Anyway, Fusion Forth is written in Motorola syntax and *almost* assembles without modification using asm20. I've been looking to see if I can hack macros into it and it doesn't look like it's an option, though. I've started work on my own, which I'll post here or on my AA blog when/if it works. I'm writing it in Perl (I know, I know, but it's easier than C for me.)

Edited April 24, 2006 by ~llama

[Tom]

I'm writing it in Perl (I know, I know, but it's easier than C for me.)

 

So what ? If I'll ever get around to writing my own assembler I'll write it in Ruby and make it somehow interpret Ruby code embedded into the source code.

Edited April 24, 2006 by Tom

[~llama]

I'm writing it in Perl (I know, I know, but it's easier than C for me.)

 

So what ? If I'll ever get around to writing my own assembler I'll write it in Ruby and make it somehow interpret Ruby code embedded into the source code.

 

I've been wanting to learn Ruby for a long time, and if I didn't have finals coming up I would use this as an excuse to learn it. That (embedded Ruby code) seems to be a great idea, one I might just steal for my Perl assembler if you don't mind, of course...

[Tom]

I sure don't mind.

 

(With the "so what" I btw. didn't mean to say Ruby is superior to Perl [although I think it is]. What I meant is that I wouldn't worry too much about using <insert-favourite-interpreted-language> instead of C.)

[+batari]

I'm writing it in Perl (I know, I know, but it's easier than C for me.)

 

So what ? If I'll ever get around to writing my own assembler I'll write it in Ruby and make it somehow interpret Ruby code embedded into the source code.

 

I've been wanting to learn Ruby for a long time, and if I didn't have finals coming up I would use this as an excuse to learn it. That (embedded Ruby code) seems to be a great idea, one I might just steal for my Perl assembler if you don't mind, of course...

Yeah, you should use what you know or whatever suits your needs (within reason, of course - I wouldn't write anything new in QBasic, except maybe for personal use.) I don't know perl at all, so that wasn't a consideration for bB, even if it would have almost certainly been more suitable. I do know awk, and I pondered that for a while. In retrospect, even awk might have been better, as I am still fixing bugs with text processing.

[~llama]

I found the p65 assembler for 6502 and 6510 that's written in Perl-- it uses a nifty parser and intermediate representation tree walker that looks like it could be adapter to just about any processor. The rest of the assembler seems to be pretty 8bit-specific but it looks like a start.

 

batari, I've looked through the bB source and found it pretty hard to understand (but I don't know much about yacc/lex)... it does seem like awk might have made for a cleaner implementation, although I wouldn't mess with success now that bB is established. Maybe the "next major revision" (bB 2.0 or 5.0 or bB X or whatever) could have a rewritten parser or something.

[Tom]

~llama: You know, awk has been somewhat obsoleted by languages such as Perl, Python, Ruby and the likes. If I was you I'd stay away from it and use Perl (or learn Ruby:)

[~llama]

~llama: You know, awk has been somewhat obsoleted by languages such as Perl, Python, Ruby and the likes. If I was you I'd stay away from it and use Perl (or learn Ruby:)

 

Oh, I hate awk Batari said he knew it, so I was suggesting maybe he could use it in a future version of bB to avoid his text-processing gremlins.

 

As for my assembler, I've got some stuff on paper for a frontend, for parsing an input file into an IR that includes labels, mnemonics, addressing modes, etc... I haven't started hacking real code yet. I printed out the listing for P65 and I'm going to hand-document it (that's really the only way I can learn how other programs work, by sitting at my desk with a pen and explaining to myself what everything is doing) to get a better grasp on how it's backend works. I'm going all-Perl on this one... maybe if I get time I can learn Ruby.

Edited April 25, 2006 by ~llama

[Tom]

Have you seen the newer Python versions of p65 ? Even if you're not going to use them, you might want to look at them anyway. They seem to be fairly well written.

[+batari]

batari, I've looked through the bB source and found it pretty hard to understand (but I don't know much about yacc/lex)... it does seem like awk might have made for a cleaner implementation, although I wouldn't mess with success now that bB is established. Maybe the "next major revision" (bB 2.0 or 5.0 or bB X or whatever) could have a rewritten parser or something.

I think the problems with the parser are small - What seems to be happening is that the CR characters in the input are getting propagated to the output. I know it sounds silly, but the same bug keeps cropping up in unexpected places.

 

The bB source code probably doesn't make much sense, but then again I'm not a real programmer - my education is in engineering. Not that this is a good excuse for writing messy code, as this is more out of laziness. I've been meaning to write in some more comments because sooner or later and erase all the commented-out lines of code or I'm going to forget myself how everything works.

 

Also, I think there may be a memory leak or two in bB... I'm not sure if I correctly deallocated all dynamic memory. Yet another thing that awk would have done for me!

[+batari]

~llama: You know, awk has been somewhat obsoleted by languages such as Perl, Python, Ruby and the likes. If I was you I'd stay away from it and use Perl (or learn Ruby:)

 

Oh, I hate awk Batari said he knew it, so I was suggesting maybe he could use it in a future version of bB to avoid his text-processing gremlins.

 

Haha... Yeah, I know that nobody uses awk anymore. I just never happened to learn any of those other languages.

[~llama]

Have you seen the newer Python versions of p65 ? Even if you're not going to use them, you might want to look at them anyway. They seem to be fairly well written.

 

I don't really know Python, but looking through the source it seems to be a really nice design, and pretty extensible. I've started making tables of mnemonics, opcodes, and addressing modes in the Perl version, but if it looks like the Python version is better then I may just dump what I'm doing and use it as a crash course in Python

 

EDIT: After continuing my search, I found that the as68 included with the sc68 package (sc68.atari.org) builds and works fine for what I'm using it for. I've started using that for my homebrew stuff... but, all this talk about an assembler written in Perl or Ruby that allows Perl or Ruby to be embedded in the assembly source has me intrigued, and I'll still be continuing with that project, albeit a little less urgently. Any interest in a collaboration on that project? The assembler could be retargetable or could work like Bruce's assemblers, where there's one main header and lots of processor implementations... anyway, I love the "embedded (Perl|Ruby)" idea so I'm going to keep working on it. Perhaps a 6502 version would be of more use to the Atari community at large, but I love 68k.

Edited April 25, 2006 by ~llama