OS X 68k assembler

[Tom]

Just don't forget: for an assembler to get any acceptance at least in the Atari 2600 community it needs to be DASM compatible (either by being compatible itself or by being powerful enough to make it able to compile DASM sources using macros or so).

Edited April 25, 2006 by Tom

[Tom]

Regarding the embedded code feature:

I have absolutely no idea how I would handle this exactly if I was writing an assembler. The basic idea is that the embedded code somehow would have the possibility to emit assembly code again, so that you could for instance embed code that calculates a lookup table without having to write a separate script which spits out the table into another file which you in turn include into the source file you're actually going to assemble.

[Bruce Tomlin]

Just don't forget: for an assembler to get any acceptance at least in the Atari 2600 community it needs to be DASM compatible (either by being compatible itself or by being powerful enough to make it able to compile DASM sources using macros or so).

Um, hello? Did you check the name of this subforum? Jaguar programming. That's pretty far away from the "Atari 2600 community". It's only got five letters in common, and two of them are "A". The main reason for DASM in 2600 programming is that enough people have already used it and written 2600 code for it that they don't want to change. However, since there esentially aren't any 2600 programmers writing 68K code, and DASM doesn't support 68K anyhow, there's no particular reason to be compatible with it for anything but 6502 code.

 

Regarding the embedded code feature:

I have absolutely no idea how I would handle this exactly if I was writing an assembler. The basic idea is that the embedded code somehow would have the possibility to emit assembly code again, so that you could for instance embed code that calculates a lookup table without having to write a separate script which spits out the table into another file which you in turn include into the source file you're actually going to assemble.

That's what macros are for. They just happen to use a syntax more appropriate for the job than Perl. If you really want Perl or some other langugage to generate assembly code, run it first, then include or link with the output.

[Tom]

Um, hello? Did you check the name of this subforum? Jaguar programming. That's pretty far away from the "Atari 2600 community". It's only got five letters in common, and two of them are "A".

Yeahyeah, I admit the moment I wrote that I typed a bit faster than I was thinking. No need to get upset and all...calm down a bit, it's better for your heart.

 

That's what macros are for. They just happen to use a syntax more appropriate for the job than Perl. If you really want Perl or some other langugage to generate assembly code, run it first, then include or link with the output.

 

Again, no need to get upset. I was talking about something I might try if I was rolling my own assembler. Ffs, you are rolling your own aswell and craft it to your liking. Perhaps reading threads more carefully might be a pretty good idea for you too aswell. Well, at least you're pretty good at spelling.

Edited April 25, 2006 by Tom

[~llama]

Well, I suppose this thread could be moved to the programming general forum now, because it's not really related to Jaguar programming, I just figured Jaguar guys knew where to find a 68k assembler.

 

I'm not going to be striving for DASM compatibility, even though what I'm really working towards is a retargetable assembler, perhaps something table-driven like TASM for DOS. I like the way Bruce's assembler handles things internally, but I think it would be better to have a "processor" directive, like DASM does.

 

Like Bruce details in his thread about his 6502 assembler, DASM is pretty weird, not like any other assembler I've used, and so I think to copy all the DASMisms would be to defeat the purpose of writing my own. That said, my primary focus here is going to be 68000 (and then once MC68000 support is working, the rest of the 680x0 family) so I don't think anybody working on 2600 code will be using my assembler for along time.

 

What are some useful directives that aren't standard? Things like ORG, ALIGN, SEG, and that are understood... what is there that could make a new assembler a "killer app"? Any feature requests that you'd like to see?

 

Bruce, I fired up MPW on my Mac Classic II (yep, I have one in my dorm room) and... well... the assembler sucks but thanks for pointing me to it... so one of the intended uses of my assembler will be 68k Macs, along with Jaguar and other 680x0 systems--you spoke a while ago of Genesis programming... if you've done any, do you use C or assembler?

 

EDIT: I've ditched Perl because it flattens lists automagically, which is stupid. I don't want to use references, so I'm either using Ruby or OCaml.

Edited April 26, 2006 by ~llama

[~llama]

Just an update: I undid my ditching of Perl, even though dealing with references is painful. I'm much more proficient in Perl than I am in Ruby or OCaml, so it only makes sense to use it on this project since I'm doing this out of need, not just for the hell of it. I'm still trying to figure out how to incorporate a DOPERL directive, but I should have a working version before too much longer. Exams are coming up, so it may be towards the end of May.

[Tom]

What was the problem with binutils anway ? I can compile them on my Debian box using something like "./configure --target=m86k-elf && make". This compiles at least, although I didn't really test the resulting binaries.

Edited April 27, 2006 by Tom

[Bruce Tomlin]

What was the problem with binutils anway ? I can compile them on my Debian box using something like "./configure --target=m86k-elf && make". This compiles at least, although I didn't really test the resulting binaries.

I think the problem was that he didn't want to deal with the gas syntax. And I don't blame him. It was created for the purpose of making a portable C compiler, not for being true to the chip maker's assembler syntax.

[Tom]

EDIT: I've been trying forever to get binutils to compile for m68k and it just doesn't want to happen.

 

 

I think the problem was that he didn't want to deal with the gas syntax. And I don't blame him. It was created for the purpose of making a portable C compiler, not for being true to the chip maker's assembler syntax.

 

Ah, be a good boy and go bitch around somewhere else, will you please ?

[~llama]

EDIT: I've been trying forever to get binutils to compile for m68k and it just doesn't want to happen.

 

 

I think the problem was that he didn't want to deal with the gas syntax. And I don't blame him. It was created for the purpose of making a portable C compiler, not for being true to the chip maker's assembler syntax.

 

Ah, be a good boy and go bitch around somewhere else, will you please ?

 

No, in this case Bruce is right on the money. I don't like the syntax and would rather use standard Motorola syntax, since it's what I'm used to. Not everything said in a negative context is bitching. The fact that it gave me trouble when I was compiling it was just the final straw that convinced me to not use gas.

[belboz]

On my OS X box I use the free Q CPU Emulator

 

http://www.kberg.ch/q/

 

I use to emulate an x86 machine and run opendos on it and the Jaguar developer tools.

 

This lets me compile, assemble, Jaguar code for the 68K and DSP's. You can't download code from the OS X box to a Jaguar running an Alpine, or BJL system though. What I do for "quick" simple testing of Jag stuff on OS X is run the Jaguar binary with Virtual Jaguar on OS X.

 

I do most of my work on the PC since I have an Alpine and need parallel port access to download code to the Jaguar.

 

Just grab the CPU emulator above and go to my website to download an image I made of the Jaguar development tools I have collected over the years.

 

http://www.hillsoftware.com

 

If anyone has trouble with setting up an x86 environment under Q, I could make a downloadable image of that runs under Q. It has freedos, jaguar dev tools, and djgpp for DOS compiling.

[Charles Turner]

Maybe too late but there's this for the Palm OS:

 

<http://www.zenonez.com/prctoolsx/index.html>

 

It's GNU gcc and binutils. Just watch out for the linker scripts...

 

Best,

 

Charles

[jbanes]

It's funny that this should pop up again. I just spent an hour yesterday building a GCC cross-compiler. There's an incredibly good tutorial on doing this over on Mega Tokyo's OS Development FAQ. The only changes you should need to make are:

 

1. Target "m86k-elf" instead of "i586-elf".

 

2. (Optionally) Use a different path than "/usr/cross". I don't know about anyone else, but I'd rather properly encapsulate such a potentially confusing piece of software. I created a sub-directory of my project called "crosscompiler". I then created a "src" subdirectory, and did the build inside there. Once built, the "crosscompiler" directory showed /bin, /include, /lib, /man, and /info in addition to the "src" directory. All nice and tidy like. The addition of the man and info pages is particularly nice as you can finally read some generic GCC documentation instead of the OS X specific stuff.

 

I understand that you probably don't like the GAS format. However, the use of GCC does afford some nicities. Instead of coding the entire shebang in assembler, you can code only the key sections in assembler and do the rest in C. The OS Development FAQ has info on all of this, including info on either building the standard libc or developing your own library.

 

I hope this helps someone. Good luck!

[Wrathchild]

Hi,

 

Aren't there issues with building a 68000 target GCC compiler as it tends to assume the miminum base processor is 68020 by default and so incompatible instructions can get included even when specifying '-m68000'?

 

Which source version would you be using for Atari dev? 2.95.x seems to be the most stable choice, but work has been done of late for GCC 3.x and 4.x (from following uClinux threads). The choice of non-MMU and no-fpu flags need to be set during the binutils and gcc builds.

 

Other areas I've never been too clear on is the options of -pic and -PIC, how do these relate to the Atari? Also, if making a cross compiler would a utility such as elf2flt be useful?

 

Regards,

Mark

[Bruce Tomlin]

For what it's worth, I've started to work on a 68000 version of my assembler, having finally gotten around to looking into Genesis tech stuff.

 

I've already got the generic part of the assembler up to 32-bit readiness, and a couple of 68K opcodes and and addressing modes to get things going. Now I need to figure out how to group all the rest of the opcodes and then write a bunch of parsing code. I disassembled the Genesis 2's boot ROM to use for testing.

 

One of the things I still want to do is to unify all my different assemblers into one binary. I've already made some adjustments to the common code to make this a little easier. If I can pull this off, then you could assemble both 68K and Z80 code from the same source file. Woot.

 

EDIT: I got it working, including making a test suite which found a few bugs, but I still need to upgrade the stuff that generates object code to use the 32-bit extensions for S9 and Intel hex files, and my makerom utility too.

Edited November 19, 2006 by Bruce Tomlin

[Bruce Tomlin]

It's not quite applicable to the Jag, but the other day I finally got my assembler unified so that the same binary can assemble every type of CPU it knows from the same source file. The main use for this right now is for the Sega Genesis, where you have both a Z80 and a 68000 in the same unit.

 

http://xi6.com/hacks/

 

(apparently I forgot to give the link last time!)

 

Version 1.8 is the current release version with a 68000 assembler, for which I've had plenty of time to kick the tires and clean up problems. Version 2.0a1 is the first alpha release of the unified version, which seems to work okay, though I'm not entirely confident on the effects of 32-bit symbols with assemblers for the 8-bit CPUs. Since uploading that last night I've added GameBoy Z80 support.

[belboz]

Bruce,

 

Very cool on the assembler. Going to play with it this weekend when I get a chance.

 

Now if you can add support for the GPU and DSP we will be set for the Jag!

 

Thanks for sharing!

[Bruce Tomlin]

I dunno about the GPU/DSP, it all depends on how "non-standard" their assemblers had to be. (For instance, the IXP-1200 network processor's assembler needs to handle branch delay slots.) But of course if I do manage to get it working, you won't be forced to put it in a different source file any more.

 

Anyhow, I've still been tweaking it and just put up a new alpha 4 version (I probably should switch to calling it beta now). There were a couple of subtle bugs that could cause it to assemble bad code, especially with invalid opcode combinations. The biggies were CMP Dn,Dn and CMP ea,An and ADD Dn,An.

 

FWIW, in case any of you want to tinker with SNES code, I looked at the 65816 instruction set and realized it wouldn't be too hard to add it to my 6502 assembler, now that I had finally cracked the 16-bit address barrier. Oh yeah, and I added GB-Z80 too.

[belboz]

Bruce,

 

I will have to check it out.

 

The Jaguar assembler (madmac) does allow you to mix your assembly code for the 68000, GPU, and DSP in one file.

 

Problem is the assembler is not XP/2000/Vista compatible.

 

As for how non-standard, well the GPU and DSP have lots of little quirks in them that need to be taken into account when assembling code for them.

[Bruce Tomlin]

I've looked at the Tom/Jerry instruction set, and it seems pretty simple, with only 14 instruction syntaxes to handle.

 

The big thing is that dealing with branch delay slots and register access time windows are the responsibility of the programmer, not the assembler. (though there is some hardware to handle register access time windows)

 

About the only problem I can see if you use MOVE PC,Rn and want to do something with the value.

 

Since my assembler is byte-oriented, all the labels will be byte addresses, and you will have to divide them by four if you want to compare with the result of MOVE PC,Rn. Branches can handle the divide by four automatically.

 

I'm also considering having pre-defined tokens for the JR/JUMP instruction, like NZ and NE=01, NCNZ and HI=5, NN and PL=14, NNNZ=15, etc., if nobody has a problem with that. If those specific tokens aren't found, a numeric value is used instead.

 

 

Any name suggestions for things would be appreciated, but right now I'm planning:

 

jaguar.c for the source file name

TOM for the GPU name

JERRY for the DSP name

 

 

FYI, I found a bug in my 68K assembler this weekend: "EOR Dn,Dn" assembles wrong, and will be fixed in the next release.

 

EDIT: I wonder if I can figure out some sort of "label scaler" feature that can right-shift non-EQU/non-SET labels during expression evaluation?

Edited February 5, 2007 by Bruce Tomlin

[Bruce Tomlin]

Okay, I've got it basically working, but the main problem is that the labels get byte addresses, not word addresses. I need to figure out some way to right-shift the code labels so that jump tables will work properly. Given the way that jumps work, I'm sure that dropping words for long branches gets done a lot.

 

In the meantime, it would be good if someone could check that it's generating the right opcodes.

[Bruce Tomlin]

So did anyone try it?

 

Since this was my first CPU that couldn't address single bytes, I figured out that probably the best thing was to scale the values of symbols when they were defined, with a WORDSIZE pseudo-op to override it (such as for using DS pseudo-ops to make structs and stuff).

 

I also fixed some subtle bugs with the 68K assembler, and added the ability to include binary files directly (INCBIN) and to generate binary files as output (but you have to specify the base address on the command line).

[Gorf]

Bruce, if you are going to do the Risc Instruction set. you should not limit the

asembler to local ram like Atari did. Some of us out here actually know how

to run code reliably out of main RAM from the GPU and we also know how to

reliably jump around in main and back and forth to and from local and main.

Let me know if you need any help.

Edited May 31, 2007 by Gorf

[Bruce Tomlin]

Bruce, if you are going to do the Risc Instruction set. you should not limit the

asembler to local ram like Atari did. Some of us out here actually know how

to run code reliably out of main RAM from the GPU and we also know how to

reliably jump around in main and back and forth to and from local and main.

Let me know if you need any help.

I really don't know anything about programming for it. I just did the instruction set as well as I could, but I don't really know what is "local ram" or isn't, or where it is or how Atari "limited" it. There's nothing more I can do unless someone tells me what needs to be done and how. If you want it to improve, then someone who knows what they are doing is going to have to actually start using it.

 

If the 68K memory map is accessible from the coprocessors, then you should be able to use labels from any address, as long as you keep in mind that the risc mode uses word addresses, and any labels defined in 68K mode have to be divided by two.

 

If all you are doing is risc code without 68K code, there should be no reason why you can't ORG or RORG to any old address you want.

[JagChris]

So did anyone try it?

 

Since this was my first CPU that couldn't address single bytes, I figured out that probably the best thing was to scale the values of symbols when they were defined, with a WORDSIZE pseudo-op to override it (such as for using DS pseudo-ops to make structs and stuff).

 

I also fixed some subtle bugs with the 68K assembler, and added the ability to include binary files directly (INCBIN) and to generate binary files as output (but you have to specify the base address on the command line).

 

How hard is it to build an Assembler? Could you show someone else how?