Lightweight cross-platform assembler library

[Procrastin8]

Is there an open-source, super lightweight WDC 65C02 assembler? My needs are somewhat strange: I can't run it as a standalone binary, I need to be able to simply include it as a static lib as part of another project. Due to this, I'm guessing that an open-source version can be adapted in this way. Other than that, anything in the C family should work: C, C++, hell even Objective-C. Any ideas?

[BigEd]

Hmm, can't think of anything. Assemblers are usually self contained and operate file to file.
There are many listed in the reference section:
http://6502.org/tools/asm/

What does an assembler library look like to you? Does it take a massive text blob and produce a large binary blob? Or is it some kind of line-by-line mini-assembler, with barely a symbol table?

[teamtempest]

Aw, Ed - what about the assembler included in your beloved Beeb's BASIC? It's possible he's thinking along those lines!

[Procrastin8]

A giant text blob would be ideal. It can operate on files if necessary, it just would be a library rather than a forked, standalone process.

[cjs]

It looks as if ca65 from the cc65 suite would do what you need. The input abstraction is a CharSource with a simple set of functions:

Code: Select all

struct CharSourceFunctions {
    void (*MarkStart) (CharSource*);    /* Mark the start pos of a token */
    void (*NextChar) (CharSource*);     /* Read next char from input */
    void (*Done) (CharSource*);         /* Close input source */
};

So basically you'd need to write a driver for this that sets that up and calls the assembler, similar to how it's done in main():

Code: Select all

    /* Initialize the scanner, open the input file */
    InitScanner (InFile);

    /* Define the default options */
    SetOptions ();

    /* Assemble the input */
    Assemble ();

(If you follow down through InitScanner you'll see how it sets up the CharSource.) Then you just link your driver against those files and you should be set!

[BigEd]

Good find Curt!

Indeed, using the 16k ROM of BBC Basic would be a way, perhaps with lib6502 to emulate it. A 64k-sized emulation of a 6502 machine running a Basic interpreter isn't all that large in terms of modern software - that's not a point which naturally occurs to me! Lib6502 is written to be an emulation library, and is plain C and freely reusable.
https://www.piumarta.com/software/lib6502/

An emulation library isn't quite the same as an assembler library, so Curt's answer is surely the better approach.

[Procrastin8]

Yes I don't need an emulation library, I built my own (though I did refer to lib6502 often in my implementation) I just need an in-process assembler. Looking at ca65 but I haven't done C in quite awhile and it's taking me a bit of time adapting it. Thank you for suggestions, though! Will update with progress at some point, I hope.

[CurtisP]

I wrote a fairly simple assembler (no macros) as part of the C02 project. Right now it reads and writes to files, but it should be simple enough to adapt it to use text and binary blobs. The files are a02.c and a02.h at https://github.com/RevCurtisP/C02.

[calschwick]

I know this is ~4 years too late, but for those in the future, I am work on a (currently extremely basic) 6502 assembler written in C++ intended for being portable.
It takes a list of lines as input, and stores the output in a list of bytes (so no file IO). It also stores the labels (and their locations) and macros.
Here's the GitHub repo: https://github.com/CalSch/6502pasm

edit: I forgot to mention, it's a work in progress and is full of problems

[Yuri]

Should be noted that one of my goals for the port of the Kowalski simulator is to get the assembler split into it's own process that can be called from the command line.
The benefits for this should be to allow folks to run the assembler portion in a build script without needing to fire up a GUI.

[BigDumbDinosaur]

Yuri wrote:

Should be noted that one of my goals for the port of the Kowalski simulator is to get the assembler split into it's own process that can be called from the command line.  The benefits for this should be to allow folks to run the assembler portion in a build script without needing to fire up a GUI.

That would be, in my opinion, a very useful feature, and not just so the assembler can be run as an independent program.

While the editor that is part of the simulator is better than average, it can’t compare to UltraEdit, the latter which I extensively use for writing BASH and PHP scripts.  UltraEdit includes a feature that makes it possible run another executable from within the editing session, which with a standalone Kowalski assembler, would essentially duplicate the workflow of edit/assemble within the simulator.

As an alternative, I could see running vim or joe to edit the source and then shelling out to assemble—I could also be editing on one terminal and assembling on another.  The less I have to deal with MS Windows, the better.

[BigEd]

Welcome, calschwick, and thanks for sharing your project! Please feel free to start a new thread, you can talk about your design decisions, your goals, your next steps, what you feel you need to fix - anything and everything!