6502.org

This is my first post to the group.

Is there such a thing as a cross assembler that accepts 6502 or 65C816 assembly language as input and produces machine code for a PC or an OS X iMac?

Thank you for your help.

Jim Adrian
jim@futurebeacon.com

Hi Jim.

I don't consider myself to be an expert on cross assemblers by any means, but I'll share my opinion anyway.

A cross assembler is an assembler that accepts assembly language for its intended target, and produces machine language for that same target. The distinguishing characteristic is that the machine hosting and executing the assembler is of a different architecture than the target.

So, I think what you need is a translator (at the assembly language level) or an emulator (at the machine language level), not a cross assembler. There are several emulators of which I'm aware, but I'm not sure if there are any assembly language translators out there, other than the human variety.

Mike B.

Welcome!


I'll be interested if someone comes up with a "yes" answer and a link; but I think it will probably be a simulator, not a direct translation from 6502 or '816 assembly language to x86 or other architecture assembly language. Computer languages often don't translate directly, and it makes for much more efficient code if you can just re-write it taking the approach preferred by the second language, which might be a very different approach. The registers will be different, the addressing modes will be different, the available instructions will be different, and so on, such that you kind of have to see what the end goal is and then approach the problem from a different direction, the direction that is suitable for the other processor or language.

As Mike pointed out, a cross assembler is a piece of software that runs on one platform with whatever processor it uses, an x86 for example, and it takes assembly-language source code for, say, the 6502 for example, and produces machine language for the 6502. It does not produce x86 machine language from '02 source code.

http://www.mpsinc.com/asm68c.html

This one is interesting, in that it mentions a tertiary "intermediate" format which is between 68xx assembly language and C. I suppose it would be possible to translate that intermediate format back to a different assembly language instead. Sadly 65xx isn't mentioned as one of the supported architectures here.

Since C compilers have become very popular and powerful with their available optimization strategies, I'm willing to bet that the target machine code could be of decent quality, even if the C source output by the translator isn't very good.

Mike B.

There's als https://github.com/ZornsLemma/lib6502-jit - a variant of lib6502 that does a just-in-time compilation into native code.

Welcome, Jim!

There's also the technique of static binary recompilation (or translation) which does all the work ahead of time (as compared to a JIT which does it during runtime and often only for hotspots.) But I don't know if there are available programs for that. See for example
http://www.dwelch.com/ipod/source.htm
http://members.aon.at/nkehrer/sbt.html
http://www.benlo.com/microchess/ - skip to Bill Forster's translation to C
Two more chess examples can be found at viewtopic.php?p=11098#p11098

See also Andrew Kelley's project at
http://andrewkelley.me/post/jamulator.html
(as mentioned at https://plus.google.com/108984290462000 ... PHzWoosXYS)

Edit: pretty sure I misunderstood the question here.

The tricky parts would be dealing with self modifying code, and I/O accesses.

It's a great advantage of approaches which read source code, that they can see what's code and what's data, and even take exception if there's funny business going on. Whereas, reading a binary means applying heuristics to see what's what. A sophisticated approach can fall back to something more like emulation if it finds itself out of its depth.

I think it's fairly common to have things like "tracing disassemblers", where simulated (or actual!) runs are used to identify what parts of memory contain code.

Indeed, but you do have to take care that you've exercised all paths, which may be difficult to do.

It sounds like I need a translator. Would the 6502 community appreciate the ability to write at least some kinds of programs on PCs and iMacs in 65C816 machine code?

I am personally most interested in encryption and text manipulation for sending messages by email.

James Adrian
jim@futurebeacon.com

I do write 6502 code from time to time, and although I can run it on a 6502, most often I'll run it in emulation. Performance is very rarely an issue, for my purposes.

For 65816 code, I would use lib65816. It's not maximally convenient, I'll admit, but it does the job.

(Whereas, for exploring programming ideas, I'd probably use C, awk, or python.)

But I'd be happy to see your project succeed. Can you perhaps elaborate on the reasons behind your preference?

Hi, James. It sounds like a really cool idea but I'm not sure how much you could get done. The two languages are "somewhat" similar in a few ways and it's not really all that hard to transition from one to the other, yet the two are very different in so many other ways.

With macros (and FASM has a macro engine specifically designed for doing this) you can simulate ANY 6502/816 instruction in x86, but...

x86 (especially) has many more registers and how they deal with data sizing (different opcodes, not SR bits), some extremely complex addressing modes, a slightly different stack, differences with the carry in both addition and subtraction, and no zero page, not to mention a flat address space in Protected Mode and a different segmenting (banking) scheme than '816 in Real Mode (and many, many more things to consider than just this little bit here) so if the question is, "Can I write 65x source in an x86 assembler and expect x86 output?" the answer is an extremely narrow Yes*. The asterisk is a killer because the two instruction sets just don't line up with each other. x86 is altogether much more involved than 65x.

Now, if you are looking to make '816 binaries using an x86 assembler, or emulation of '816 instructions, then sure, it can be done with macros and custom code -- I do lots of both actually. Also, it's very possible to translate old 16-bit x86 source code to '816 (there's a lot out there still!) and I have done it many times (3D gfx code, string handling, number conversions, etc.) to get something I needed in '816 but wasn't sure how to do it.

P.S I have an endless library of good (great) x86 & 65x digital books if you need them.

I don't think I could list all of my complaints about higher-level languages. I appreciate many of the technical difficulties. I prefer a discussion of the incentives seen by 6502.org members to control PCs and Macs and possibly introduce 6502 assembly language to the Linux world.

I prefer the sense of hardware necessity in assembly language. I dislike starting a program with a lot of declarations about data types and I especially dislike the arbitrariness of the syntax of C and related languages. I would rather use a processor status register than a two hundred page manual. I don't believe in the supposed efficiency of higher-level languages because it discounts the programmers option to define a system of subroutines; but all this and more like it is besides the point. Can the frame of mind and directness of simple assembly languages be introduced into the wider computing market? Do we all believe in that?

James Adrian
jim@futurebeacon.com