Hello all. Can I ask for a bit of your time? Via Garth's encouragement, I would like to share a project of mine that is still incomplete, but has been in the making for decades (mostly in my head). By sharing my journey with you all and asking for your input, I am hopeful that I will be able to find the inspiration to allow me to get this thing fully specified, simulated, and implemented on an FPGA. An assembler, BIOS, and eForth-based operating system are to be developed as soon as the simulator compiles and runs successfully on a PC host. Garth W., Jeff L., Ed S. and (especially) Dieter M. have been invaluable in coaxing me toward these goals, and I couldn't have come this far without their generosity. However, I am stretching my spare time and expertise to their limits, and have decided that the best chance to reach the finish line will be to start a thread here and seek more help. I am a bit stubborn, and I don't want to lose control of the project, but I need to light a fire under my butt or it will continue to languish in spec doc purgatory.

Here are a few search links to provide some background information; the oldest posts from 2013 are a bit out-dated, but the general idea of what I'm trying to do should still be apparent:

http://forum.6502.org/search.php?keywor ... mit=Search

https://groups.google.com/forum/#!searc ... Csort:date

search.php?keywords=65m32&terms=all&author=&sc=1&sf=all&sk=t&sd=a&sr=posts&st=0&ch=300&t=0&submit=Search

In a nutshell, the 65m32 is a 32-bit, word-addressed microprocessor, inspired by the 6502, 6809, pdp-11, and Nova. Its assembly language looks mostly like a cross between 6502 and 6809 assembly, but with a few twists, described below.

Overview

The 65m32 is a 32-bit microprocessor. The address bus, data bus, internal registers, ALU, and (with few exceptions) the instructions themselves are all 32-bits wide. I/O is memory-mapped. Each 32-bit instruction contains several bit fields which, altogether, define a flexible range of possibilities. Using a subset of these possibilities, the 65m32 can easily approximate the behaviors of the long-established but less powerful 8-bit machines from the 65xx and 68xx families. Although this property can facilitate comprehension and source translation from one to the other, compatibility is not 100%, as will be explained later. The focus of this document is on the new 32-bit machine. Points relating to the 65xx and 68xx families are subordinate, and will be mentioned as they arise.

The first implementation of the 65m32 has a simplified programming model, in which a user program has full access rights to all 16 of the 32-bit registers, and full access to all 4 GW of physical memory. Future upgrades may include a supervisor/user mode mechanism, and allow a more complex framework for multiprocessing, virtual memory, and inter-process messaging and protection, through additional processor status bits, additional processor registers, and memory management hardware. These upgrades will be designed to provide this extra functionality without requiring any major modifications to well-behaved software written for the original model.

There are ten basic 65m32 registers, and six other advanced registers, to be described later.

Register a is the system main accumulator, and is the 32-bit equivalent to the 6502's 8-bit counterpart of the same name. If any non-trivial arithmetic and/or logical operations are to be performed, register a is the appropriate conduit for these operations. Logical instructions that modify a affect ^NZ , and arithmetic instructions that modify a affect the c register and ^NVZC , in a manner quite similar to the 65xx family. The BCD arithmetic mode is selected by setting ^D , and affects operations involving a , but in a more complete manner than the 65xx family.

Registers x and y are functionally equivalent, and are for general purpose storage and pointer arithmetic. Loads to x and y affect ^NZ .

Register z is reset to zero at the beginning of every instruction fetch, and provides the useful constant 0 (and, in certain cases, +/- 1 ). A load to z affects ^NZ , making it the equivalent of the 68xx's tst instruction.

Registers b and u are functionally equivalent, and are for general purpose storage and pointer arithmetic, just like x and y . The only difference is that loads or adds to b and u do not affect any condition flags, making them more useful as effective-address and stack-frame pointers than x or y .

Register s is the system stack pointer, and its use is implied in any operation that includes a push or a pull, unless specifically stated otherwise. A push operation pre-decrements s before storing, and a pull operation post-increments s after loading. Loads or adds to register s do not affect any condition flags.

Register n is the system instruction pointer, and it is automatically incremented after every instruction fetch. Loads or adds to register n do not affect any condition flags.

Register p is special-purpose, and contains processor status information, including, but not limited to, the information contained in its 6502 counterpart of the same name. All load, logic and arithmetic instructions that alter the contents of registers a , x , y and z cause two or more of the condition flag bits to be updated automatically, in a manner quite similar to the 65xx family. In order to prevent the condition flags from being changed by effective-address calculations, stack operations and branches, all load and add instructions that alter the contents of registers b , u , s , and n have no condition flag effects. Bits 4 and 5 are currently unused by the ALU, but are modifiable by the programmer, who may use them however he or she wishes. Bit 2 and bits 8 to 31 are reserved for future expansion and capabilities … although they may be viewed and modified in the initial version of the hardware, there is a high likelihood that such behavior will cause problems in future versions.

Register c is a full-width 'carry' register, and is used to hold the high-order bits of an arithmetic result which cannot fit in register a . It is potentially a source and a target for the rol , ror , rot , inc , dec , adc , sbc , cdc , mul , and div instructions, and a target for the ash , lsh , asl , lsr , cmp , add , sub and cdd instructions, but only when register a is either specified or implied. The ^C flag in p is similar to the register c , but is only a single bit, and is used when memory cells or registers other than a are modified by certain instructions. ^C may be updated without affecting register c , but every load or update to register c will cause ^C to be updated to reflect the zero or nonzero result in c .

The 32-bit operation word is divided into several fields:

[ooooppp]
The 7-bit op field specifies the type of operation that will be performed, like load, add, store, shift, compare, etc. Here is the 65m32 op-code matrix. Many of the mnemonics will be instantly recognizable to 65xx and 68xx programmers. Several will look a bit foreign, but a complete understanding can be delayed until after the operand structure has been introduced.



Operations shown in the above matrix are preliminary, and may be moved, modified, or deleted without prior notice. The operation fields marked ??? are reserved for future expansion. The top four rows of the matrix may become privileged-mode operations in future revisions of the 65m32, but are executable by any program for now.

[rrr]
The 3-bit operand register field specifies which register will participate in the operand calculation. Any one of the basic registers, including a and n , can be chosen (except c and p ).

[iiiiiiiiiiiiiiii]
The 16-bit embedded numeric field specifies the numeric portion of the operand. In most (but not all) of the basic instructions, the numeric portion is added to the value contained in the operand register to form the actual operand (the operand register is not modified by this particular action). The embedded numeric field is only 16-bits wide, but is promoted to 32-bits (by duplicating bit 15 into bits 16 .. 31) before being fed to the operand adder.

[mm]
The 2-bit operand mode field specifies the mode in which the operand will be used by the operation. There is a literal mode, in which the operand is used at 'face value' (immediate mode in 6502-speak), and there are three direct modes, in which the value of the operand is used as an effective address into memory (direct-page and absolute modes in 6502-speak). All basic 65m32 operations use an operand, so the rrr , mm and iiiiiiiiiiiiiiii fields in the machine instruction relate to the operand field in the assembly language as shown:


i indicates the position of the signed 16-bit integer embedded numeric, which may be a constant or a label. In the assembly language, a missing embedded numeric defaults to the value 0 , and a missing operand register defaults to the register ,z . Operand registers are always directly preceded by a comma, to distinguish them from labels, so lda #x and lda #,x are not equivalent and will assemble as different machine instructions ... the first would be assembled as lda #x,z (with x assumed to be a label) and the second would be assembled as lda #0,x .

# indicates the literal mode, and is conceptually a superset of the 65xx's immediate mode. This mode has some unique properties, discussed in the next section. Please note the difference in nomenclature here. Literal mode on the 65m32 is equivalent to immediate mode on the 65xx and 68xx devices.

+ indicates the post-increment direct mode. The value in the operand register is fed to the operand adder, then the register is incremented by 1 before the execution of the machine instruction.

– indicates the pre-decrement direct mode. The value in the operand register is decremented by 1 before being fed to the operand adder, and before the execution of the machine instruction.

If # , + , and – are missing, the simple direct mode is the default. In this mode, the operand register is not modified as part of the operand calculation.

On the 65m32, the three direct modes cause the machine operation to use the result from the operand adder as an effective address to memory, making them conceptually a superset of the 65xx's abs abs,x abs,y dp dp,x and dp,y addressing modes. The 65m32 has no built-in facility for the 65xx's (d) (abs) (d,x) (abs,x) (d),y and (d,s),y addressing modes (which specify an address of an address), but we will see later how these modes can be efficiently synthesized when needed, with far more flexibility and generality than their 65xx counterparts.

Please note the difference in nomenclature here as well. Direct mode on the 65m32 is equivalent to absolute or direct-page modes (indexed or non-indexed) on the 65xx and 68xx devices.

[cccc]
The 4-bit conditional field specifies the conditions by which the instruction will be executed or skipped, based on various different combinations of the status bits, like overflow, negative result, greater than or equal, etc. In the assembly language, a missing condition field is assumed to be always.


If the condition is true, the instruction is executed in its entirety. If the condition is false, the instruction is skipped in its entirety. In all skipped instructions, the operation and any applicable memory accesses and index register side-effects are all canceled. Notice that the 65m32 allows the conditional execution of any basic instruction, not just those related to branching, which allows the elimination of many “hop” branches around short sections of conditionally-executed code, as long as any condition flag side-effects of the conditionally-executed instructions are consistent with that intent.

So, how does all of this fit together to make the 65m32 a joy to program in assembly (at least for me)? I don't want to tease, but I also don't want to make this post too long, so I'll save some assembly code snippets (including a full explanation of the unique properties of literal mode) for my next post. In the meantime, I am open to questions, suggestions, and critiques.

Thank you all for your time.

Mike B.

Thanks for posting your write-up Mike - looking forward to the next instalment.
I'm interested to see how you deal with indirect addressing, as that was historically a very important innovation.
Also interested to see how Z not being zero can help!

Mike:

Thanks for posting your write up. I've been following your processor concept from the snippets of its details that you've revealed in some of your posts on forum.6502.org. I have a better appreciation of its architecture from your post above.

Since you've specifically asked for comments, I'll provide one or two to get the conversation started. It appears to me that you have two competing concepts rolled into your processor: (1) speed; and (2) ease of programming. For speed, you've adopted a word addressable architecture. It appears that you've relegated processing of data less than 32 bits in width to the programmer. This decision certainly simplifies the instruction fetch, and memory interface. In my opinion, this is a false economy. I think that you would be better off allowing data to be accessible in 8, 16, and 32 chunks, and providing instructions for manipulating memory in those standard data widths. You can keep the instruction at 32 bits, and enforce instruction alignment on 32-bit word boundaries for reasons of speed, ease of decoding, etc. On the data handling side, I think that providing a way to handle 8, 16, and 32 data chunks will simplify the programming in a manner that will be much appreciated.

I can see ways to handle 8-bit and 16-bit I/O devices on your processors memory bus. However, I can also see the need to manipulate data smaller than 32 bits in memory. The programming problems associated with processing packed 8-bit or 16-bit character strings will lead, I suspect, to storing these type of data structures in an unpacked manner. I think that will prove to be very wasteful of memory even though you've provided as much as 16 GB in your architecture.

Although I like the architecture of the word addressable Nova computers, I think the byte addressable PDP-11 provided a better approach to the handling of strings. You've incorporated concepts from both of these architectures in your design. For improved ease of programming, I think that you should consider allowing your design to directly address and manipulate 8-bit and 16-bit data. The added complexity needed in the memory interface and in your ALU is minor compared to the simplification this capability will provide when dealing directly with packed 8-bit and 16-bit quantities.

Once again thanks for sharing the details of your 65m32 concept.

Thank you Ed and Michael. Regarding Michael's comments (your participation is greatly appreciated BTW):
Speed would be nice, but is not an immediate goal ... simplicity is. If I could get 20 MIPS using current hobbyist-grade FPGA technology, I would be giddy with excitement. Ease of programming comes naturally to me, because I am the architect, but I most certainly don't want to be the only 65m32 assembly language programmer, so I have become mindful of quirks that may turn potential programmers off.

For example:
My original design didn't even allow direct random access to the full 4 GW in a single instruction; a long literal load to an index register (via 0,n+ addressing, a la pdp-11) had to precede the access, because a full-width address couldn't embed within the instruction word. Garth was silently vexed when I told him this, but Dieter came to my rescue with his clever (maybe even original) "magic value" in the embedded constant, which would trigger the hardware to discard the narrow constant and use the next word in the instruction stream for the full-width operand constant. This works for literal and direct modes, but adds a "wart" to the architecture (instructions are no longer always one word long). I reluctantly agreed that it was necessary.

The 65m32's inability to address individual bytes is definitely eccentric, but (as you said) not without precedent. I have struggled to come up with a clean way to do this, but the complexities which I unearthed in my attempts are more than I am capable of tackling. I have much respect for your opinion, but I confess that I will probably be using UTF-32 strings and pack/unpack subroutines for the narrower chars ... that is, unless those "inspiration pills" I ordered on-line finally get here and perform as advertised

I am exhausted from work today, but I will post part 2 of my overview here soon. This will explain some of the mysterious mnemonics like "cdc" and "sla", why there is no "jsr" in the matrix, the "magic value" implementation, and the unique properties of literal mode.

Keep the suggestions coming. I promise to sincerely consider all of them before stubbornly doing it my way!

Mike B.

Great. looking forward to your next installment. I too am a fan of the solution that you and Dieter have apparently included in your architecture to deal with long immediate and direct address values. I suspect that feature is partly driven by some of the features of the ARM architecture.

Fixed length instructions do have some benefits, particularly in deeply pipelined implementations. But your assertion that speed is not the only driver indicates to me that your implementation should consider variable length instructions. In this case then, some judicious judgement will be necessary so that the instruction complexity doesn't get out of hand as it did with the VAX-11 instruction set.

One additional 32-bit word in the instruction should probably be the limit. The impact on a pipelined implementation would be minimal, and I suspect very beneficial in the overall CPI. The inability to load long constants will be reflected in the need to implement instruction sequences to build those constants in registers. Disturbing the pipeline slightly to avoid the need to fetch and execute the several instructions needed to build long constants will improve performance far more than the disturbance it might introduce into a pipelined implementation of your architecture. Furthermore, I can't see that feature inhibiting the implementation of a pipelined architecture to support future speed improvements of your architecture.

An architecture that you may want to read about, and possibly borrow some ideas from, is the architecture of the PDP-6 and/or PDP-10. I would like very much to find the time to implement a processor based on this architecture.

Another architecture that I think you may like to exploring is the architecture of the CDC 6600. It has a fairly unique way of addressing memory that you may find fits some of your ideas regarding your register usage.

Again, looking forward to your next installment.

@Michael: Ah yes, the big iron! I time-shared on a CDC Cyber and a VAX 11/780 in my college years, but never got to program them in their native assembly languages. I ran a one-pass Pascal compiler and FSE (full-screen-editor) on the Cyber, and the Ultrix cc compiler and cc68 cross-compiler (along with vi) on the VAX. A curious circumstance: my assembly language course was IBM 360, but there was no 360 on campus, so we ran a 360 assembler/simulator on the Cyber! The VAX, pdp-10 and CDC 6600 are very impressive and personality-rich machines, but I can't get the hang of the assembly languages of any of them ... they are just too foreign for me to put forth the effort to learn in my middle-age. I learned 6502 assembly when I was a teenager, at the peak of my IQ ... it hadn't deteriorated from college partying yet.

Moving on to part 2:

“What about all the old familiar 65xx mnemonics not included in the matrix above, like jmp , bne , pla , tax , iny , clc , jsr , rts , …?” The answer lies in the 65m32's simple yet flexible operand modes, which allow these instructions (and many more) to be synthesized in a single basic 32-bit instruction.

Because the 65m32's literal mode has the useful property of a built-in operand register, it is able to synthesize the 65xx's txa , tax , tya , tay , tsx , txs , inx , iny , dex , dey instructions (and many more) with a simple load or store instruction. The closest analogs to this would be the lea instructions of the 68xx and x86 families. tax translates to ldx #0,a and dey translates to ldy #-1,y … variations on this theme are too numerous to list.

Here are a few translation examples using the 65m32's “indexed” literal operand mode, in which the operand is used at “face value”:

Note that all of the 65m32 examples above have literal mode operands, even though several of their 65816 counterparts use implied, relative, or absolute modes. Also, note that by treating the 65m32 instruction pointer n in the same manner as the other registers, a layer of indirection is apparently removed in the translation of the last four examples. This is due to the 65m32’s implementation of the instruction pointer … it employs n as just another register with regard to loading and storing. In other words, loading a literal value into n has the effect of jumping to the associated direct address.

Here are some translation examples using the 65m32's “indexed” direct operand modes, in which the operand is used to form an effective address to memory, for read, write, or read-modify-write:

Note that by treating the instruction pointer n in the same manner as the other registers, a layer of indirection is once again apparently removed in the assembly language translation of the last three examples from above. In other words, loading a direct value from a memory cell into n has the effect of jumping to the associated indirect address. It is my intention to provide many of the more familiar 65xx/68xx-style mnemonics as aliases in the 65m32 assembler, to improve readability and ease-of-transition for those users:

Since the 65m32's direct modes are comparable to the 6502/65816's direct-page and/or absolute addressing modes, an auxiliary pointer register technique must be used to synthesize the (d,x) (d) (d),y and (d,s),y addressing modes of those processors. There is no built-in equivalent for these modes on the 65m32. Fortunately, this pointer address set-up usually can be done once, outside of any tight loops, making the performance hit negligible:

Note that although one or two additional instructions are required to set up register b as the pointer, the checksum loop in the last example above is actually two instructions shorter (thanks to the add and dbn instructions).

Full-width numeric operands

The 65m32 is 32-bits all-the-way, but most instructions require an opcode and operand data to specify a literal value or an address, and it is generally impossible to fit a 32-bit operand and an op-code into 32-bits.

One way that the 65m32 gets around the problem is to automatically promote the 16-bit embedded numeric value contained in the instruction to 32-bits, by sign-extending it (duplicating bit 15 into bits 16 to 31) before adding it to the contents of the index register. But that only works most of the time, depending on what is being done with the operand. [-32767 ... 32767] is a respectable range that can be used for small increments, constants and offsets, but doesn't enable the 65m32's full potential.

Another way that the 65m32 avoids this problem, at least for large literals , is to allow the use of the direct mode operand 0,n+ to allow a literal value to be placed in-line, directly after the instruction. This method has been used by the pdp-11 with great success, but can only be used to provide the equivalent of extended-literal mode on the 65m32, because of its limited indirection capability. In the case of a conditionally-executed instruction of this type, it is important for the 65m32 programmer to be aware that activation of the conditional skip mechanism will cause the trailing literal to be treated as an instruction, because the auto-increment of n would be skipped as well. Although it is conceivable that this type of behavior could have an obscure use, it is more likely to be a programming error. If this type of behavior is not desirable, the following method should be more appropriate.

The third (and most flexible) way that the 65m32 gets around the problem is by treating the embedded numeric value of -32768 in a special manner. When an instruction containing this value is fetched and decoded, it automatically triggers a second fetch, and allows in-lining a full 32-bit numeric literal or address immediately after the instruction. The -32768 “magic” value is then discarded, and the full-width constant is used in its place. Unlike the 0,n+ method, which can not implement extended-direct, this method works equally well in literal and direct operand modes. When composing small (<64kW) programs, this extended-operand mode is typically only needed for large constants, like bit-masks and such, since the embedded 16-bit value provides plenty of reach for most relative branch targets, increments, initializations, etc. The assembler automatically recognizes the need to 'promote' a one-word instruction to a two-word instruction, and the 65m32's conditional execution mechanism 'knows' to skip the second word as well, if applicable. Some examples:

While translating a DTC Forth variant from 6xxx assembly to 65m32 assembly, I have so far only found a few occasions in hundreds of instructions where this extended-operand technique is necessary, and they were only needed because of the four-char-per-word dictionary name storage convention that I have implemented. For accessing any memory location in the 65m32's 4GW address space, this technique is only necessary if the target address falls outside of the range [-32767 .. 32767] surrounding any index register, including z and n . Otherwise, the basic single-word instruction suffices, making the range [-32767,z .. 32767,z] the 65m32's equivalent to the 6502's zero-page addressing mode, and the range [-32767,n .. 32767,n] the 65m32's equivalent of the 6xxx family’s PC-relative addressing mode.

Part 3 ... coming soon!

Mike B.

Really good to see to this thread appear, Mike! What you've posted is well-written, too -- something that doesn't happen by accident. And I don't need to tell you I'm already a big fan of this project.

Regarding addressing: if addresses are expressed as 0 to 4 GByte (not GWord), I readily agree the HDL code will be daunting. That's if the thing is done "properly." By that I mean being able to freely access words, half-words and bytes from any address. But there's a half-way solution that's worth considering, and that is to express addresses in bytes... but with the restriction that you can't access any word or half-word that spans a word boundary. In other words, no mis-aligned accesses. This'll make the HDL quite a lot easier. (It also makes 65m32 programming slightly harder, but only compared to having full support for byte addressing. Compared with no support you're much better off.)

Full support is something that could be added to a later revision, perhaps. But you won't have that option if version 1 has committed to word addressing. To be fair, word addressing does have the advantage of pushing the memory ceiling from 4 GB to 4 GW, but how much is that really worth compared to the other side of the tradeoff? Hard to say.

As for instruction encoding, you'll need to allow space in your opcode matrix for the byte- and half-word operations. Simple loads and stores are all you really need. But, if you have space, something like the 65xx's TSB and TRB would be nice, too.


I'm completely sold on the memory addressing modes -- very flexible, elegant & cool! But IMO there's something that's been neglected, and that is the ability to NOT address memory!

I'm saying I think you need more registers. Ideally your code would execute as quickly as it can be fetched. But, since there's no cache for code or for data, the two are forced to take turns accessing memory. More registers can alleviate that -- more so in some situations than others, of course, but we can agree there's a clear advantage.

Everything's a tradeoff. To define more registers we need a wider [rrr] field. That means using fewer bits somewhere else -- such as in the [cccc] field or the [iiiiiiiiiiiiiiii] field. Either of these could go on a diet and still retain most of its utility. But I vote for the [iiiiiiiiiiiiiiii] field. IMO the penalty of shrinking [iiiiiiiiiiiiiiii] to 15 bits is worth mentioning, but hardly major. What it gains us -- 8 scratchpad registers -- is far more significant, IMO.

(When AMD created x86-64 they boosted the register complement -- they saw benefit despite the fact caching is already a given. Without caching the more-registers argument is even more persuasive.)

best regards,
Jeff

Thanks for the post Mike. I've been looking forward to learning more about 65m32.

As Dr. Jeff and Mike already mentioned I have to third the motion for 8/16 bit data support. Maybe leave some room open for 64 bit operands as well. In my one core I had just 32 bit word support like the 65m32, but when I went to write some software found it was better to have at least byte loads and stores available. I then added an "orb" instruction standing for "or byte" and "stb" for store byte instruction that worked only in the lowest 4GB instead of 4GW. In short the core and software turned into an ugly monster with the oddball support for bytes and I decided to re-write it without the "orb" and "stb" instructions, but instead using prefix bytes to indicate byte or half word addressing.

The magic number doesn't need to decode the full 16 bits, if desiring to save some LUTs you could just check the top nibble for $8. But it would mean the magic number would be used more often.

Could the assembler / compiler support alternate mnemonics for some of the instructions ? I'm really fond on the JSR / JMP instructions as opposed to program counter loads.

More registers might help. But one thing I've noticed is that the block memory in an FPGA is just as fast as a processor core. So if running just in block memory it may not be as critical to have so many registers. It depends on target applications I guess.

re the "more registers?" question... and I'll try to be brief, 'cause there's other stuff to talk about. Also, I'm looking forward to Part 3 of Mike's doc!

TBH, the existing register complement would suit me alright, because my #1 project would be to write a Forth kernal. And, Mike, I know you've coded Forth primitives as a means to road-test the 65m32 instruction set. I'm sure those test cases worked out fine. But other folks have different goals, and that's where the extra registers become important.

Although I don't know much about compilers (other than Forth's), I've often read that the mainstream compilers like a CPU with lots of registers, for performance reasons (and maybe for code density too). Another example -- one where I do have first-hand knowledge -- is Interrupt Service Routines. Due to our 65xx/68xx backgrounds, it's easy for folks like us to take it for granted that every ISR begins by saving some registers and ends by restoring them. But I've done some MSP430 coding, and that really opened my eyes. No save/restore in the ISR -- very snappy! That's because I could afford to let the ISR have some reg's for its own exclusive use. And there are other examples, harder to describe, in which extra reg's result in a positive outcome.

Rob, you probably do this differently but AFAIK Mike's design will handle code and data accesses sequentially. If that's the case then, even if block ram were used, data accesses delay code accesses and thus increase execution time. A larger register pool reduces the number of memory accesses required for data.

Agreed. And I'm admitting Forth is an application that doesn't get much benefit from a larger register pool. But in that regard it's somewhat of an anomaly.

Evaluating tradeoffs means looking at BOTH sides of the equation. And we can resume this discussion at a later time. When we do, maybe someone can make the opposing argument -- namely, that it's really important the [iiiiiiiiiiiiiiii] field be 16-bit, not 15.

J

Wow! You guys really like your 8-bit bytes, don't you? If I had decided on a 36-bit or 40-bit design, would it have made any difference in your advice? Maybe I'm just hopelessly eccentric, but I never liked bytes that much ... they seemed too limiting. Computer programming and design has always been a hobby of mine, not a profession, so I confess that I just don't see the universal appeal of them, at least not enough to complicate the auto-increment and auto-decrement modes, lose 75% of my address space, use more op-code real estate, deal with alignment [and endianness] issues ... Garth hasn't chimed in yet, but I would venture a cautious guess that he wouldn't mind working almost exclusively with words in the embedded projects he is so good at designing. Of course, there are the issues of data density, translation, and compatibility with some existing paradigms, but I'm prepared to make an (almost) clean break ... I hope that I don't regret it, because you guys have certainly given me fair warming.

@Jeff: Yeah, we have been through this discussion before, and I value your point of view (as well as your superior experience). However, if I chose to wander from the 65xx "look and feel", I still would want to maintain a certain level of orthogonality, so I would need to expand my op-field as well as my reg-field, thereby stealing two bits from my embedded constant ... hey, 8-bit op, 4-bit reg, 4-bit condition, 2-bit address mode, 14-bit constant ... it sure does look tidy in hexadecimal! I'll have to meditate a bit further on that ... 16 registers are too much for my brain to juggle, but in the long run I don't want to be the only software composer, so concessions may be necessary.

@Rob: Yes, I really like JSR, JMP, RTS, etc. I would make every effort to include them at the earliest possible stages of assembler development.

Well, soldiering on to part 3:

"dbn", "cdd", "cdc", "sla", "pda" ... I'm using a lot of three-letter combinations, but haven't stumbled into any rude ones yet, at least not in standard English. As I told Garth, I'm quite fond of uniform-length mnemonics, and the 65m32 is no exception. This fondness is not without its awkward moments, though. "cdc" is "complement and add with carry", "cdd" is "clear carry, complement and add", "dbn" is "decrement and branch if not zero", "sla" is "store and pull accumulator", and "pda" is "push and load accumulator".

"pda" and friends are a direct (and useful, IMO) outgrowth of the 65m32's treatment of n (the instruction pointer) as "just another register". "pdn" is a direct translation of "jsr", so it's a must-have, but how many times have you guys needed to borrow register a for a while in a section of code? If you want to live dangerously, you just use it and hope that the side-effects on the rest of the system are harmless. If you want to live carefully, you examine all possible entries and exits from your code section, and ensure that the side-effects are harmless. Or, you just push the register, load something into it, process that something, store that something somewhere, and pull the original value. "pda" and "sla" streamline the beginning and ending of that sequence for register a, and registers x, y, b, u, and n have their own machine instructions for the same type of benefit.

A 65m32 instruction execution consists of a read of the operation word, an optional read of the extended operand, an optional read of the direct operand (or a pull), and an optional store [er, write] of the direct operand (or a push). Many useful literal-mode instructions can do their work in a single memory cycle, but it is certainly likely that a complex arithmetic operation would require enough additional time to stall this "one memory access per machine cycle" pattern. My initial design will treat any operations complex enough to foul up this critical path with instruction emulation traps; "mul" and "div" are obvious candidates, but there certainly should be others ... I won't really know for sure until I choose a host FPGA.

I wanted to get into the unique properties of literal mode, but I'm feeling a bit loopy from a hard day of working my tired old body on my run-down old house. I will have to put it off until part 4, and apologize ahead of time if any of the above is utter nonsense. It's definitely bed-time for Mr. Barry ...

Mike B.

Okay, let's dig in to part 4. But first, an answer to Ed's question about non-zero values of register z.

... good ways to store zero or "false" into a memory location or register without affecting any condition codes. But, what if we want to store a 1 or a -1 into a memory location without dirtying a register?

... since the index register is updated before the store, and z is allowed to change during the execution of an instruction, the first will store a 1 in (label), and the second will store a -1 in (label). Register z is reset to zero during the next instruction fetch. And we can store any value into a register with something like

... this is an unusual form of literal addressing, in which the numeric part of the operand is added to the source register instead of the operand register. The result is "stored" into the operand register (x in this example) without affecting any condition codes. Here's a more complete explanation of "split literal" mode.

Irregular Forms of Some Basic Instructions

The operand mode field (especially the literal mode) may be treated in an irregular manner by certain instructions. Let's start with some examples of 'normal' behavior. In the following examples, the condition flag side-effects are determined by the instruction, not the operand:

The above examples illustrate the 'normal' behavior of the literal operand mode. The operand adder adds the contents of the operand register to the embedded constant, and the instruction uses this sum to modify the destination register. But, what should a write or a read-modify-write instruction do with a literal value such as this? In most microprocessors, this mode of addressing is undocumented or forbidden, but the 65m32 makes use of it, by simply modifying the behavior of such instructions:

Above is the first example of irregularity in the operand calculation, and is called 'split-literal’. The 'normal' behavior for the operand adder would be to calculate (3 + x) , but (3 + a) is calculated instead in this instance. This behavior is utilized by the literal modes of the sta , stx , sty , stz , stb , stu , sts, stn, sla, slx, sly, slb, slu, sls and sln instructions.

The read-modify-write group: inc , dec , tsb , trb , rol , ror , asl , asr , lsl , lsr ... these should all be reasonably familiar to 65xx and 68xx programmers, and they act exactly as expected in the direct modes, where the operand specifies a memory address:

BUT ... what about when the operand is literal mode? Since both the embedded constant and the operand register are present, even for the literal mode, it is natural to do a read-modify-write on the register rather than the memory location, and to use the embedded constant to alter the behavior of the operation. This mode is called 'split-literal', since the two operand components rrr and iiiiiiiiiiiiiiii are used independently, rather than being added together in the operand adder:

So, in the cases of inc and dec , a positive numeric constant excludes ^C , and a negative one includes ^C , but does NOT change the direction of the operation. Why not just get rid of dec and allow an inc with a negative constant to replace it? If inc was allowed to decrement as well, and rol to rotate right as well, then there would be no way to dec or ror a memory cell using the direct modes, because the numeric constant would already be used up as an offset in the effective address calculation! It is important to note that the use of ^C makes it easier to detect unsigned "wrap-around" when the increment or decrement constant is greater than one.

A numeric constant of 0 for all of these instructions results in the equivalent of a tst # instruction, which affects ^NZ , but nothing else:

In the cases of numeric constants of 0 , and in other cases as well, there is significant redundancy in the instruction set, where dozens (or in some cases, many hundreds) of different instruction bit-patterns do exactly the same thing. This situation is not very desirable when there are 8-bit instructions, but is terribly difficult to avoid for 32-bit instructions without making the instruction decode process much more complex. With billions of possible individual instruction encodings, there is plenty of room for this redundancy, and it even provides a method by which a compiler or assembler (or human coder) can produce machine code with an "individual" quality or "signature" without affecting performance or code-density.

Are things starting to get strange yet? More strangeness coming up soon, in part 5 ... I'll be sharing some longer code snippets,

Mike B.

You guys ready for part 5? I hope so ...

Let's try coding some useful subroutines, like a memory move (actually a copy). If the ranges overlap, we need to have two versions; one that copies "up" and one that copies "down", to prevent interference during the copy. Here's a 6502 version, courtesy of Bruce Clark:

... and here's the same thing (actually better, because it chooses the correct direction by itself) ...

The compare instruction at the top is used to decide the direction, and the [cc] additions to mvdown save a "bcs" instruction by sliding straight down to moveup if the carry is set, at a net cost of a couple of cycles.

Here's a typical Sieve of Eratosthenes, first in C:

... then in 65c816 assembly, courtesy of Eyes and Lichty:

... then in 65m32 assembly, courtesy of yours truly:

Note: the op-code map changed since I wrote this, so the hex is wrong, but the word count is correct.

Part of my 65m32 journey has included a renewed interest in Forth and its fascinating properties. The 65m32 architecture lends itself well to Forth, and it's no coincidence ... I tailored the machine instruction set to favor a DTC setup, with TOS in register a, although STC and ITC can be economically implemented as well:

Here are some eForth primitives. a is TOS, s is PSP, u is RSP, and y is IP:

A lot of DTC primitives translate to a single 65m32 machine instruction plus a single machine instruction NEXT. This implies that a competent STC version should be about twice as fast, but I am not ready to expend another time-slice of my limited attention span to pursue this yet. When it comes to Forth, it seems that the 65m32 closely resembles the 6809 in instruction count. I have a lot of respect for the 6809, and the 65m32's register names and operand structure reflect this, but my first love is the 6502, and the mnemonics reflect that.

Is anyone thoroughly confused yet? I'm doing my best, but my thought processes can get a bit disorganized, and I can't always tell whether or not I'm making any sense until someone breaks me out of my trance.

My next installment will be a call for discussion of some architectural details that I haven't finalized. I am just a hobbyist, so advanced programming techniques aren't among my stronger qualities. I don't want to cripple the 65m32 with some foolish assumptions, so I'll be counting on you guys to advise me.

Mike B.

Mike:

Great set of demo programs. Clearly shows the expressive power of the architecture.

I'd like to suggest that you provide a comment regarding the example source code you included with your assembler code for common FORTH words; it appears to me to be 80x86 assembler, but I don't see where you've explicitly defined the processor.

Thanks, Michael. The example (commented out) eForth source is x86, and came from this excellent .pdf by Dr. TIng:

http://www.exemark.com/FORTH/eForthOverviewv5.pdf

How about another code sample brain teaser?

The task is to convert a potential digit from UTF-32 to binary if and only if it lies in the interval ['0'..'9', 'A'..'Z'] and is less than base, for values of base in [2..36].
The ldb ,s+ nips the UTF-32 char from NOS into b.
The dec #-'0',b makes the UTF-32 to binary adjustment for [0..9] and causes any char below '0' to fall all the way through to the stz #,a by setting ^N and clearing ^C.
The tst [pl]#-10,b causes any digit in [0..9] to fall through to the cmp [cs]#1,b by setting ^N.
The adb [pl]#-7 adjusts any digit above 9 down by seven without affecting any flags.
The cpb [pl]#10 invalidates the range above 9 but below A by clearing ^C and falling through to the stz #,a.
The cmp [cs]#1,b invalidates any digit >= base by clearing ^C and falling through to the stz #,a.
The stb [cs],-s tucks the translated digit back into NOS, but only if it has passed all tests for validity.
The stz #,a and dec [cs]#1,a place the appropriate flag in TOS.

This makes very careful use of the side-effects of conditionally executed instructions, and could be considered needlessly tricky, but I believe that it's the shortest and most efficient way to do the task (for the 65m32, not necessarily for the human composing, debugging, and/or maintaining this little gem).

Mike B.

Thanks for the code examples - it's a crucial part of a new architecture, to see what the software would look like, and not always made explicit.

As I've said elsewhere, I'm fully in favour of a word-based architecture. Bear in mind that the people who will speak up (on anything) are the people who disagree!

However, it's worth perhaps spelling out what the shifting and masking would look like if anyone felt compelled to deal with packed data - such as you might get from network or storage, depending on what your I/O looks like. It might be that shift-by-8 starts to look like a very useful operation.