Mike Kohn's naken_asm

[joe7]

Finally sorted it out, now it uses zp, zpx, zpy for 0-255 but checks to make sure that an instruction is actually available for those modes. If not, then it assumes a 2-byte mode ensuring the passes line up.

So it should work as expected now. Thanks a lot for the suggestions.

[joe7]

I have re-written the 6502 assembler, and added a new one for the 65816. Traditional syntax is supported where possible, but there are some limitations. (The most glaring omission is lack of % for binary.)

A documentation project has been started (still working on '02/'816 docs):
https://github.com/mikeakohn/naken_asm/tree/master/docs

[BigDumbDinosaur]

joe7 wrote:

(The most glaring omission is lack of % for binary.)

Are you working toward implementing binary notation?

[joe7]

BigDumbDinosaur wrote:

Are you working toward implementing binary notation?

I can't really fix that in my modules, which are part of a larger suite of assemblers that share the same code base. (I think there is a conflict with the % being used for modulus in expressions.) I may be able to parse single binary values myself, but expressions would still require the 10101010b format.

[BigDumbDinosaur]

joe7 wrote:

BigDumbDinosaur wrote:

Are you working toward implementing binary notation?

I can't really fix that in my modules, which are part of a larger suite of assemblers that share the same code base. (I think there is a conflict with the % being used for modulus in expressions.) I may be able to parse single binary values myself, but expressions would still require the 10101010b format.

Surely context would allow the assembler to determine if % represents an operator or a radix (i.e., %, @ or $ to respectively represent binary, octal or hex notation). For example, a statement such as I = %10100101 would be unambiguous, as would J = I % 2. In fact, assuming whitespace is properly used, the expression J = %10100101 % %00000010 could be unambiguously evaluated. The general rule your parser would have to implement is a radix cannot be separated by whitespace from the value it modifies, whereas when % is an operator it must be surrounded by whitespace so it is seen as an operator, not as a radix. Also, there is a secondary rule that is implicit when % represents modulo: it must be preceded with a number or an expression that evaluates to a valid number, as in J = I % %00000010. The notation J = % 00000010 would be syntactically not acceptable.

[GARTHWILSON]

The assemblers I've used also allow the trailing "B" for "binary" or "H" for "hex," for example AND #10100101B or AND #A5H, just as they would accept AND #%10100101 or AND #$A5. Radix has to be set for decimal of course so the "B" does not get mistaken for a hex digit like it would if Radix were set to hex. A trailing "O" for "octal" might require more careful looking to avoid confusing it with a zero, but I have never had any reason to use octal. Ever.

[joe7]

I think it ignores whitespace (like a C compiler would). Probably not much I can do, but I thought I should mention the quirk.

You can do these currently (need to update docs):

Code: Select all

0b11001100
11001100b

0x4444
4444h
$4444

[BigDumbDinosaur]

GARTHWILSON wrote:

...but I have never had any reason to use octal. Ever.

You would if you were a UNIX or Linux user, that is, one who routinely works at the shell prompt level. Some UNIX and Linux commands take octal values as arguments, e.g., chmod and umask. chmod, in particular, tends to be used a lot, as it is how one changes file access permissions. Ergo a symbolic notation was developed for it long ago to spare the novice user the indignity of having to mentally convert a bit-wise permissions value into its octal equivalent. However, the octal notation is probably more intuitive for the experienced user.

Supermon 816 accepts octal values, as well as binary, decimal and hex. For example, the operand @077 would be evaluated as octal.

[joe7]

I've added a disassembler for 65816, mainly because that module is needed for list file generation (-l option in the assembler). I'll also need it for the simulator display when I get around to that. In those roles, the number of storage bytes can be known, but for now 16-bit register sizes are assumed if used as a normal disassembler.

The WDC guidelines have aliases for some things, as well as one and two byte results for the byte selection operators > < and ^. I could support those things, but are they that important?

I don't think % for binary is going to work out, but otherwise I think all of the traditional syntax is implemented. Which never was mandatory for this project, but it would have been nice to have my cake and eat it too.

[barrym95838]

joe7 wrote:

... The WDC guidelines have aliases for some things, as well as one and two byte results for the byte selection operators > < and ^. I could support those things, but are they that important?

In this man's opinion, yes.

Mike B.

[BigEd]

I suppose, Mike, you're saying that a project with some non standard syntax or missing important features is good for the person who built the project, but probably not good for a general audience?

[joe7]

BigEd wrote:

I suppose, Mike, you're saying that a project with some non standard syntax or missing important features is good for the person who built the project, but probably not good for a general audience?

Well I'm very sorry for sharing my hard work with people that might be interested in it. WDC sells a compliant assembler if that is what someone prefers.

I won't be posting here anymore, but thanks for having me.

[BigEd]

Goodness me, Joe7, don't do that! It's always better when we see encouragement here rather than the opposite, but do note that I could easily have misunderstood what Mike meant.

And consider, if just one interaction can push a person away from a whole community, how could any community possibly survive?

[Dr Jefyll]

Is this a case where a message has gotten misinterpreted due the written medium's lack of cues from tone and body language? I suppose it's bound to happen from time to time. (Myself, I find nothing offensive about Ed's query, or about Mike's answer to the question that was posed).

-- Jeff

[GARTHWILSON]

Dr Jefyll wrote:

Myself, I find nothing offensive about Ed's query, or about Mike's answer to the question that was posed

Same here. I didn't find anything offensive. If someone is puzzled, or even feels they need to play "devil's advocate" to get something cleared up (which I don't see here), it promotes valuable learning. Learning and improving oneself are why many of the projects here are carried out.