So to force myself to learn Forth beyond the toy examples, I'm trying to write a disassembler for the 65c02. Things are moving along nicely, interrupted by bouts of cursing, re-reading the books, and subsequent flashes of insight, as should be.

Except that I can't figure out an elegant way to code the relative branching with the BEQ, BRA etc. commands, specifically the negative versions, and I'm assuming by now I'm missing something very simple. Any help would be appreciated.

The basic structure is that I have a "jump table" with 256 entries that I fill with execution tokens, one for every opcode (the idea is to make it easier to expand this to a 65816 later, so I'm not trying to be clever with rows and columns of the 65c02 opcode table). The program takes an opcode from the byte stream (c@) and uses it as an offset to said table to find the token for that word, and then executes it. If the word -- say, BRA -- needs the next byte in the stream, it picks it out and advances the PC itself. This works well enough and already produces output such as:


And so forth (no pun intended). But how do I convince an instruction such as BPL ($10) that the byte it has fetched with c@ is two's complement and not unsigned? Obviously I could check the highest bit and do the rest the hard way, but that just doesn't seem right. I assume I'm lacking some basic insight to the way numbers are represented and handled in Forth.

Thanks for any pointer (or rather in this case, xt)!

(The program itself is in gforth, and I'd be happy to upload it here if anybody is interested once I'm done. As an exercise, I can only recommend something like this, because it forces you to understand stuff like cells, execution tokens, and factoring the book examples don't.)

Something like this, maybe (off the top of my head):



It's a little ugly, but should work. On the other hand, I'd just as soon aknowledge that I'm on a specific host CPU and write a CODE word to do the damage more quickly. If you can figure out WHY it works, so much the better. And someone could probably come up with an even more clever solution.

Said more clever solution:



Enjoy.

or you could do it as a primitive, something like:

Code:

CODE  SIGN-EXTEND-BYTE   ( b -- n )
    LDA  0,X
    BPL  1$
    DEC  1,X
1$: JMP  NEXT
END-CODE

(Modify the syntax for the particular assembler in your Forth.) It takes less memory and is much faster. Since there's already a S>D word that extends a single to a double, you could shorten the name above to something like B>N.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I too have been reading up on Forth, and unlike scotws, I'm not yet at the stage of working with it.

I may be missing something, but how is it that location 1,x is 0 so that DEC 1,x effectively sign extends the byte in location 0,x?

_________________
Michael A.

0,X is the low byte of the top-of-stack (TOS) cell, and 1,X is the high byte of the same cell. C@ ("character-fetch") puts the fetched value in the low byte and zeroes the high byte; so assuming you used C@ to get the byte, you can be sure the high byte of the cell is 0. It makes it easy.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That works nicely, thank you. Left to my own devices, I would have probably tried something with an IF ...

Garth, I'm using gforth on my MacBook to learn Forth, because I can use my normal tools such as vim. I've heard that being eaten by certain wild animals is preferable to having to program assembler on an Intel CPU ... on the 65c02, I'd certainly go native, though.

Thanks, everybody!

Garth:

Thanks for the reply. In that case, your little word is a nice and simple sign extender for bytes/chars.

_________________
Michael A.

You guys are probably going to think that I'm a weirdo ...

I have never tested or even written a single Forth program, but I find its 'interpreter' to be fascinating. I've spent many hours studying how the language gets things done at the lowest levels, using 6502 and pdp-11 version list files, translating them to non-existent processors of my own design, etc.

I suppose that it would be analogous to someone obsessed with knowing what every gear, nut, and bolt was doing inside a car's engine compartment, but having no clue how to drive. Yep, I'm a weirdo!

Mike

Actually, what's attracted *me* personally to Forth is that it is one of the earliest point-free (tacit) programming languages.

a little off-topic, but that's ok...


A few of those bolts can drive you nuts, but once they're in place, they just do their job and you don't have to look at them again. I remember wrestling with DOES> and ;CODE when I wrote my '816 Forth (which let the user invent his own defining words-- part of the "pearl of Forth"). I never did implement vocabularies, as my onboard Forth assembler sticks the addressing mode onto the op codes so for example there's AND#, AND_ABS, AND_ZP,X, etc., none of which conflict with Forth's AND, so a separate assembler vocabulary is not needed. Also, my workbench computer does not have an editor (screen editor or otherwise) as it has a very minimal human interface and all program-writing and editing is done on the PC with a professional programmer's editor, so there's no need for a separate vocabulary for that either. I have in a file a nice write-up someone sent me on how vocabularies are made in 6502 ITC Forth, and I never got through it and really understood it. Leo brodie covers how to switch and use vocabularies in "Starting Forth" in the chapter, "Under the Hood" (how appropriate, huh?) but says at the end, "The handling of vocabularies is highly system-dependent and controversial. The '83 standard wisely skirts the details. And so shall we. Check your system documentation." That's on p.220 of the 2nd edition, ©1987, which I have in paper. It looks like they removed it in the new edition on line (http://www.forth.com/starting-forth/sf9/sf9.html) which includes ANS Forth though, and it just says,

Forth Vocabularies

Forth systems provide ways to manage the dictionary by organizing words into vocabularies. For example, the programmer can create a vocabulary for all words related to a specific project. The system can be instructed which vocabularies to search for a word, and in which order.

For information about vocabularies, refer to the ANS or ISO Forth standard or to the Forth Programmer's Handbook, which offers discussion of scoping, vocabularies and search orders.

The standard words my earlier version discusses are CONTEXT, FORTH, EDITOR, ASSEMBLER, CURRENT, and DEFINITIONS, and of course you can add your own vocabularies.


And it's so expandable, and the user can get under the hood and modify and extend the compiler itself; so just because it's one of the earliest doesn't mean it can't keep growing with you. It can.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Ah, you might want to read http://www.yosefk.com/blog/my-history-with-forth-stack-machines.html then, a blog post about one computer programmer's experiences with Forth and the two types of people who use it. The comments are very interesting, too. Warning: Involves dead frogs.

Great read - thanks!

Definitely a good read. Some of my favorite quotes from it:




I found this interesting:
because before the ANS standard, people were complaining that there's no effective standard (I thought the '83 standard plus a lot of things in common usage and documented in Starting Forth, Thinking Forth, Forth Dimensions, and other publications were enough of a standard), and then when the ANS standard came along, it seemed to give Forth more credibility outside the inner circles. I've added some things from ANS, but I don't like being confined to some parts of ANS. Fortunately, in his book "Forth: The New Model," Jack Woehr said it's not the committee's intention to force anyone to comply.

Edit: Jeff Fox has a great article entitled "ANSI Forth is ANTI Forth" at http://www.ultratechnology.com/antiansi.htm, and Chuck Moore, the inventor of Forth agrees. See why.

continuing:

We seem to have a good combination here on this forum.

and finally,

Reading all the comments would take a long time, but although I only scanned the first 10-20% of them, I found them favorable.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

"Committees only serve to retard forward progress, which is occasionally valuable."