WDCs W65T32 Terbium 32-Bit Processor

[bvold]

This is a new 32-bit design that Western Design Center is working on for to compet with the ARM processors. I want to disscuss what this could mean for the 6502 and 8-bit world in general. Please share your opinions.

bvold,

[kc5tja]

The Terbium is, according to what little information is public, fully backward compatible with the 6502 and 65816 processors. Therefore, it has relatively little impact for these CPUs except for providing a nice upwardly compatible upgrade path.

Inferring from available information, but which is NOT confirmed, the Terbium will likely be a word-addressed (not byte-addressed) machine. I've written about this elsewhere in this forum. Moreover, the processor will (at least for running 6502 and 65816 binaries) have similar, if not exactly the same, timing.

When more information is made available, we'll see how close my predictions come.

[bvold]

I just think it's really awesome that there is going to be a 32-bit version. A more powerful member of the 65xx family will be really interesting to play around with. In a way from the little info thats out it reminds me of the Motorola 68000.

[kc5tja]

I was asked where I got my information from. The most factual information came from here: http://www.westerndesigncenter.com/wdc/ ... essors.cfm . Note -- until we see real silicon, this is all just vaporware. Everything else I believe to be true about the Terbium is based on logical deductions based on the information presented on that page, and are admittedly to be predictions.

So far, one of my predictions is now confirmed: a word-addressed, not byte-addressed, machine, with a true 4.2 GW (8.4GB) of memory space. YUMMY!

I can't wait for more information personally -- I want to see if my prediction on how the opcode space is handled is correct.

[GARTHWILSON]

bvold wrote:
> In a way from the little info thats out it reminds me of the Motorola 68000.

The 65816 has already performance-matched the 68000 in the Sieve benchmark for years, even though it's much simpler to use than the 68000.

There have been other hobbyist projects (although the hobbyists are engineers too) to make a 32-bit 6502. I believe Ruud is one one of these (65GZ032), although their goal seemed to be 6502-related only in that it would execute 6502 code in emulation mode, while it was almost entirely different in 32-bit mode.

[Ruud]

GARTHWILSON wrote:

I believe Ruud is one one of these (65GZ032)

I wish I was indeed. No, Gideon Zweijtzer is the engineer behind the 65GZ032.

[TMorita]

I tried to get on their (WDC's) mailing list about Terbium discussions, but they rejected me.

I'm a little worried about the Terbium - I've worked on GCC for about ten years, and I've seen how innocuous instruction set anomolies can cause major problems for compiler back-ends. Hopefully they won't make too many of the classic instruction set mistakes.

Toshi

[fachat]

Toshi,

can you give some hints or pointers on what mistakes to avoid when designing an instruction set?

Thanks
André

[kc5tja]

Maximum bang for minimum buck is THE overriding factor for any CPU instruction set. Remember that when the 6502 came out, memory was faster than CPUs were, so it made sense to move as much program state into RAM as possible. Hence, zero-page.

Now-a-days, it's just the opposite; it's easier to have CPU registers instead of something complex like zero-page. As a result, your instructions can be made simpler. RISC processors epitomize this, where the 3 operands are register ID fields ONLY. No addressing modes at all -- just registers. And, quite often, you even lack word-width specification. ADD will produce a 32-bit sum (assuming a 32-bit CPU), regardless of whether you used an 8-bit, 16-bit, or 32-bit load instruction to fill the registers.

Which brings us to the issue of addressing modes on the load and store instructions. Minimize them as much as possible. Ideally, one, and only one, addressing mode would be provided. However, practical matters often suggest two, sometimes three. Either way, definitely a far cry from the 65816's 24 gob-smackingly complex addressing modes.

The ultimate form of this is MISC -- Minimal Instruction Set Computers. These are typically 0-operand instruction sets. As such, they rely on a data stack to manage parameters. Since instructions require no operands (since they're always implied as the topmost n items on the data stack), the instruction encoding can be much smaller. 5 bit opcodes on MISC processors is not unheard of. In a 16-bit word, this means you could pack 3 MISC instructions per 16-bit word. Hence, one opcode fetch grabs 3 instructions. Over a 65816-like bus, expanded to 16 bits, this means you have one cycle for opcode fetch, and up to 3 cycles for load/stores. Therefore, cycle times are predictable at 1.3 cycles per instruction. Again, this is assuming the simplest possible processor implementation. And, yet, it still makes the 6502/65816's performance pale in comparison.

[kernal34]

It appears all references to the Terbium seem to have been removed from WDC website. What does this mean? Most likely they have stopped development.

[BitWise]

kernal34 wrote:

It appears all references to the Terbium seem to have been removed from WDC website. What does this mean? Most likely they have stopped development.

Its still there and on the January 23rd WDC sent out a mail shot that contained the following

Quote:

Terbium – Your 65xx Future!


--------------------------------------------------------------------------------

We have had many of you request information about our Terbium microprocessor plans.

We feel that the 65xx brand microprocessor's Instruction Set Architecture (ISA) has never been fully understood and especially in light of other well know ISA′s. In addition‚ since 1975 the language of computer architecture has evolved to the point that some of the features of earlier microprocessors deserve a fresh description with current terminology. That said‚ WDC will reframe the 65xx ISA with this new terminology– add some features and call it the Terbium ISA.

Some questions need answers:

1. Why does WDC feel compelled to name the architecture?

We choose to name this ISA because it is neither a Reduced Instruction Set Architecture (RISC) nor a Complex Instruction Set Architecture (CISC). Calling it the Terbium ISA just says we are different. Our opportunity requires that we point out the differences and state the value proposition. We plan to provide a "white paper" description of the Terbium ISA to begin brand recognition.

2. Why use a name like Terbium?

We use Terbium because it is the 65th element in the periodic chart of elements. Sixty–five is our favorite number! We plan to keep 65 as part of all our microprocessor′s number identifiers.

3. What are the goals for the Terbium ISA?

We plan to compete with all 8–‚ 16–‚ 32–bit or beyond microprocessors. In addition‚ we plan to promote our licensees as Terbium Alliance Partners (TAP) in support of a variety of industries. We plan to call on a few of you to review evaluation kits of our next generation Terbium microprocessors when they are available later this year.

4. What will be the first use of the Terbium brand name?

We have begun using the Terbium brand name with our ANSI Standard Plum–Hall Validated W65C816S C compiler development tool suite Integrated Development Environment (IDE). Our Terbium IDE (TIDE) interfaces with our existing developer board and can be configured for our customer′s application boards and licensee′s ASIC microcontrollers/SoC′s.

We hope you not only enjoy seeing our efforts as they come to fruition‚ but also continue to profit from existing and future Terbium microprocessors!

I just wish they would get around to posting the data sheets so we can take a look at the beast.

[kc5tja]

Interesting -- so the 65816 is a 16-bit Terbium then? That doesn't seem right.

Or, putting it another way, you better believe that the 32-bit processor will make design decisions that are not conducive towards applications written in C. Sorry, TMorita.

However, for Forth, the existing 65816 architecture is adequate for reasonable performance. In fact, MachineForth maps more or less nicely to the 65816 architecture (though not to the 6502).

There are many things I wish would be done differently though. I would love to see D and S be 32-bits, so that it can address all of available RAM. Edit: I would also like to see instructions that increment or decrement A, X, and Y by larger quantities than 1. 2, 4, and 8 would be nice, but having an immediate 4-bit operand field would be better, like the 68000's addq family of instructions.

Still, it's a nice architecture if you're willing to concede to its limitations. Used correctly, the 65816 offers performance comparable to a 68000, which is impressive, considering the 68000 has a wider data bus and is a true 32-bit architecture. Its biggest problem is randomly accessing data anywhere in its address space. It's doable, but inconvenient, due to the nature of the addressing modes available. Edit: I believe these issues are why the 65816 has a 20% performance hit compared to the 68000 on the Sieve benchmark.

[TMorita]

fachat wrote:

Toshi,

can you give some hints or pointers on what mistakes to avoid when designing an instruction set?

Thanks
André

There's a huge list of processor misfeatures which cause problems for compiler code generation. Here's a list of the more common ones:

1. Special registers.

This is by far the most common problem. These mistakes can range from minor to major. A few examples of this are:

MIPS/SuperH: multiply returns result in a special register. Minor mistakes,

SuperH: fixed register for register+register indrect addressing mode. Major mistake.

SH-5 media: branch target registers. Must load address into BTR to jump to it. Major mistake.

Compare result in special register: Most non-RISC and even some RISC processors have these. Minor mistake.

2. Lack of offset+register indirect addressing mode

This is a pretty huge and serious mistake. When the compiler generates code for these types of machines, it tends to eat a huge number of registers for addressing structs and classes. Intel Itanium. Major, major mistake.

3. Non-orthogonal read/write addressing modes

This is when the memory reads and writes don't use the same addressing modes. SuperH has this problem. Major mistake.

4. Separate instruction/data address spaces

AMD 29K. Enough said. Major mistake.

I could list more, if you're still interested.

Toshi

[kc5tja]

Quote:

1. Special registers.

The 65816 is a major offender in this area, unfortunately. But, this is an intrinsic of any accumulator-based architecture.

Quote:

2. Lack of offset+register indirect addressing mode

The 65816 has this addressing mode in the form of dp,x and abs,x -- however, the scope is backwards. It'd be better to load the pointer into the register, and use the 'abs' field as the offset. Still, within a certain scope, it is useful.

Quote:

3. Non-orthogonal read/write addressing modes

Fortunately, the 65816 does not suffer from this problem. In fact, I've never heard of an architecture that had this issue.

Quote:

4. Separate instruction/data address spaces

This is not a mistake; this is an architectural facility that allows concurrent instruction fetching and data memory access. This is how high-performance microcontrollers work.

The 65816 may or may not have this problem, depending on the memory model you choose. However, I don't see this as being a critical or "major" mistake. At best, it's an annoyance.

[TMorita]

kc5tja wrote:

Quote:

...
This is not a mistake; this is an architectural facility that allows concurrent instruction fetching and data memory access. This is how high-performance microcontrollers work.

The 65816 may or may not have this problem, depending on the memory model you choose. However, I don't see this as being a critical or "major" mistake. At best, it's an annoyance.

From a compiler code generation point of view, it is indeed a mistake.

For example, in certain situations, gcc needs to generate dynamically generate code at runtime. On most processors, this can be done on the runtime stack, but if a processor has separate instruction/data address spaces, this can't be done.

I'm not aware of any microcontrollers which have separate instruction and data address spaces. I'm aware of quite a few DSPs which have this, but not any microcontrollers.

Toshi