Using the Y-reg as the IP ptr

[GARTHWILSON]

IamRob wrote:

Does any of the X-reg JSR/JMP's take their address from the Direct Page or are they all absolute?

None are direct page. Penciled-in notes I have in my old paper copy of WDC's excellent programming manual [*] say on the JMP page (page 459), for JMP(addr), "If I understand p.592 correctly, addr is in bank 0, but destination is in current program bank. p.383 & 212." and for JMP(addr,X), "addr is in current program bank, as is the destination. See p.382 & 212." and for JMP[addr], "addr is in bank 0, and is 3 bytes, so destination is totally defined there and not dependent on current program bank. p.384." However, since I've only used the 65802 so far, it would be good to get confirmation from someone else who deals with the '816 in a situation where they have code in multiple banks. I don't intend to have Forth code in other banks besides bank 0, only have data in the other ones.

Quote:

if the Direct Page was set to $2000, with X-reg being zero (0), would a JSR (0000,X) or JMP (0000,X) takes the address at $0.1 or $2000.2001?

It won't care what your direct page is set to. The effective address will be read from addresses 0000 & 0001.

[*] "Programming the 65816—Including the 6502, 65C02 and 65802" 6502/65816 programmer's manual by David Eyes and Ron Lichty. This is definitely the best 65xx programming manual available, and a must-have for every 65xx programmer! It starts with the basics, followed by architecture, the CMOS 65c02's many improvements over the original NMOS 6502 including added instructions and addressing modes and fixing the NMOS's bugs and quirks, and then the natural progression to the 65816; a thorough tutorial, writing applications, then very detailed and diagrammed information on all 34 addressing modes, at least a page of very detailed description for each instruction, with info on every addressing mode available for that instruction, then instruction lists, tables, and groups, of all 255 active op codes, plus more. 469 pages. From Western Design Center. (.pdf) Note: There were many problems with the earlier .pdf version that were not in the original paper manual; but in late March 2015, WDC scanned and OCR'ed the paper manual and posted the new, repaired .pdf.

[IamRob]

barrym95838 wrote:

Most of my primitives are so short that it seems wasteful to force them all to NEXT (even a single instruction 3-cycle NEXT) but that's DTC for ya ...]

Me thinks you give too much credit to using DTC and not enough to those new smancy pancy 32-bit instructions.

What would those instructions look like in 16-bit?

And if those instructions are that efficient, it probably means you won't need to access any memory beyond 64kb!

[IamRob]

BigEd wrote:

All absolute: whether something uses Direct Page is a function of the addressing mode, not the address itself.

Darn! Would have made programming a little easier, and at the same time could have offered some serious benefits.

[IamRob]

GARTHWILSON wrote:

None are direct page. Penciled-in notes I have in my old paper copy of WDC's excellent programming manual [*] say on the JMP page (page 459), for JMP(addr), "If I understand p.592 correctly, addr is in bank 0, but destination is in current program bank. p.383 & 212." and for JMP(addr,X), "addr is in current program bank, as is the destination. See p.382 & 212." and for JMP[addr], "addr is in bank 0, and is 3 bytes, so destination is totally defined there and not dependent on current program bank. p.384." However, since I've only used the 65802 so far, it would be good to get confirmation from someone else who deals with the '816 in a situation where they have code in multiple banks. I don't intend to have Forth code in other banks besides bank 0, only have data in the other ones.

I am somewhat aware of the JSL/JMP 24-bit instructions that use the square brackets and that handle the bank navigating.

[barrym95838]

IamRob wrote:

Me thinks you give too much credit to using DTC and not enough to those new smancy pancy 32-bit instructions.

I have been working on that design for decades, and it's only half done, just like my 1962 Ford Ranchero project (hasn't seen the street since 1991). I fear that I'm spending too much time polishing the furniture before I'm even done carving it, but it's a character defect of mine.

Quote:

What would those instructions look like in 16-bit?

They don't fit. I think 24 would be the absolute minimum width for that architecture.

Quote:

And if those instructions are that efficient, it probably means you won't need to access any memory beyond 64kb!

The local area up to $1FFF words above or below any register-held address comes at no cost (encoding-wise), but 4GW are available at any time using extended addressing. Byte addressing comes at a significant cost, because nothing is 8-bits wide.

[IamRob]

barrym95838 wrote:

I have been working on that design for decades, and it's only half done, just like my 1962 Ford Ranchero project (hasn't seen the street since 1991). I fear that I'm spending too much time polishing the furniture before I'm even done carving it, but it's a character defect of mine.

I am in the same boat. I have a 59 Ford Econoline, snub nose and open box, I would really like to get going again. The engine is right beside the driver in the cab.

barrym95838 wrote:

The local area up to $1FFF words above or below any register-held address comes at no cost (encoding-wise), but 4GW are available at any time using extended addressing.

I thought I was pretty computer savvy, but GW? GigaWatts? GigaWords? GigaWorth? GigaWhat?

What does working on this design mean? Emulation? or designing your own breadboard CPU?

[barrym95838]

Since this is your thread and you're asking the questions, I guess it's okay to share that I intend to finish my Ranchero with a 1985 Ranger frame, suspension, engine and transmission. I have already spliced them together at the floor line, but the firewall and dashboard need a lot of work, and the fuel-injected 2.3L is severely worn out and needs to be replaced. The end-goal is to make it into a Sunday driver that I can enjoy and even use for light hauling while gasoline is still being sold to the general public.

When I said 4GW I meant giga-words. My 65m32a (and big brother 65m36) designs are floundering inside an incomplete specification document and a coincidentally incomplete simulator written in C. The end-goal is to put at least one of them into an appropriately-configured FPGA and write (or port) an OS and a few languages, but I can't even imagine when that'll happen.

[GARTHWILSON]

Introducing the 65m32

Quote:

I have a 59 Ford Econoline, snub nose and open box, I would really like to get going again.

One of those that noses over if you brake too hard? I drive an '88 15-passenger E350 Econoline Clubwagon with a 460 V8. I got it for camping, but we have not done any of that in years. It's huge, and has come in handy many times we needed to move big stuff. If I'm careful, I can get 11+ mpg in town; but I drive less than a thousand miles a year, so it's an economy car.

[barrym95838]

I've never had the pleasure of seeing or even knowing a '59 Econoline existed. Do you really mean a 1961? I briefly owned a '66 Econoline and a '74 Econoline, but they were both basket cases and I gave them up for scrap, along with a '73 Datsun 240Z and a '76 AMC Gremlin. They've all been gone for about 20 years, when I had to downsize my collection of hoopties. Come to think of it, the Ranchero started out for me as a basket case too (and plausibly still is), with its Flintstone floorboards, broken heater and rotten brakes, but at least I put a couple hundred semi-useful miles on it before I made the dubious decision to tear it down and "restore" it.

[IamRob]

I guess it could be a '61 as some of the parts on it say 1960. But I think the registration I got listed it as a '59.

By the way, I took this picture and scanned it with a Quickie Scan on a IIGS quite a few years ago. Thus the grayscale.

[IamRob]

Here are some comparisons with 65816 routines compared to Forth definitions, in bytes.

QUERY 16/13
EXPECT 63/104 - 56 bytes optimized 6502. The 6502 wins due to having to switch the 65816 to emulation mode for byte processing
NULL 48/48 - this one surprised me. I was hoping to do better than Forth
ENCLOSE 59/88 - 88 bytes is my optimized 6502 code with most regular Fig Forth listings are at 98 bytes.
-TRAILING 24/36
." (DOTQ) 27/33
COMPILE 17/18
WORD - 53/67
-FIND - 28/30

In general, most 65816 routines are coming out smaller than the Forth definitions and should also execute faster due to not having to interpret all the words in the definition. I am looking forward to get this up and running to see and feel the speed.

[BigEd]

IamRob wrote:

One of the biggest advantages of keeping the TOS in both the Acc and Y-reg when entering a word definition is so you can go either way and just re-use the one that is not needed. Check out doFETCH and doSWAP.

I'm really liking this unexpected twist, adding a TAY in NEXT to save a lot of shuffling in other words.

[barrym95838]

Yeah, every primitive that needs the TAY has it already done, so the size benefit adds up byte by byte. But every primitive that doesn't need the TAY pays a slight speed penalty, which also adds up slowly. Seems like a reasonable trade-off, but it certainly is a matter of taste.

[IamRob]

barrym95838 wrote:

Yeah, every primitive that needs the TAY has it already done, so the size benefit adds up byte by byte. But every primitive that doesn't need the TAY pays a slight speed penalty, which also adds up slowly. Seems like a reasonable trade-off, but it certainly is a matter of taste.

So far I am only half done and I count 15 places where I don't have to save the Acc first with something like STA N/LDY N and 42 places I don't need a TAY first. All variables and constants will need a TAY, and how many of them are there?

The STA N/LDY N pairs are starting to add up and will eventually be more of a speed penalty than the TAY in NEXT for every word. Plus 3 bytes are saved for each STA N/LDY N pair and 1 byte for each TAY, which means so far 87 bytes have been saved by having TOS also in the Y-reg.

You will eventually find that it is more a speed increase than a trade-off. Give it a chance.

[barrym95838]

IamRob wrote:

The STA N/LDY N pairs are starting to add up and will eventually be more of a speed penalty than the TAY in NEXT for every word.

Do you have a reason for using N like that? What's preventing you from replacing those STA N/LDY N pairs with a simple TAY in the words that need it?