View unanswered posts | View active topics It is currently Thu Mar 28, 2024 7:42 pm



Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4
 Introducing the 65m32 

65m32: Stupid or neat?
Stupid 0%  0%  [ 0 ]
Neat 86%  86%  [ 6 ]
Undecided 0%  0%  [ 0 ]
65m32? 14%  14%  [ 1 ]
Total votes : 7

 Introducing the 65m32 
Author Message

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
Hey all ... sorry it's been more than a month, but I had some other business that required my attention (attempting a "graceful" exit from an unrelated forum that required manually redacting over 4800 posts spread over eight calendar years).

My op-code matrix still isn't ready to share, but I think I might be ready for some feedback on my newest register spec (registers are named in bold lower-case, and condition flags are in bold upper-case, usually preceded by a "^"):
Quote:
Register a is the system main logic and binary arithmetic accumulator, and is the 32-bit equivalent to the 6502's 8-bit counterpart of the same name. If any non-trivial binary 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.

Register b is the main BCD arithmetic accumulator. When BCD arithmetic operations are used, the operands are expected to be valid ten's complement BCD numbers, and the d register and ^NVZC are affected accordingly. Operands containing invalid BCD bit patterns will produce repeatable but unspecified results. When BCD arithmetic capabilities are not needed, the b and d registers can be used to hold any numeric values or addresses.

Register c is a full-width "carry" register, and is used to hold the high-order bits of a binary 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, ndc, cdc, mul, and div instructions, and a target for the ash, lsh, asl, lsr, ada, sba, nda and cda instructions, but only when register a is either specified or implied. The ^C flag in f 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.

Register d is the BCD "carry" register, and is used to hold the high-order bits of a BCD arithmetic result which cannot fit in register b. Every load or update to register d will cause ^C to be updated to reflect the zero or nonzero result in d.

Register e is the system execution pointer (aka program counter), and is automatically incremented after every instruction fetch. Loads or adds to register e immediately alter execution flow, but do not affect any condition flags.

Register f is special-purpose, and contains processor status information, similar to the information contained in its 6502 counterpart p. All load, logic and arithmetic instructions that alter the contents of registers a, b, i, j, w, 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, any load, add or exchange operations which target the contents of registers e, k, q, s and u 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. Bits 2 and 3 and bits 14 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 likelihood that such behavior could cause problems in future versions.

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. Load, add and exchange operations which target register s do not affect any condition flags. There are two stack pointers, but only one can be active due to the identical names and instruction encodings; the ^S flag in f selects the active register; this act of selection does not directly affect the contents of either register.

When the flag bits of the same name are clear, registers i and j are functionally equivalent, and are for general purpose storage, counters and pointers. Load, add and exchange operations which target i and j affect ^NZ, similarly to the 6502's 8-bit counterparts x and y. When corresponding bits ^IJ in f are set, the registers access vectors for the IRQ1 service routine and the IRQ2 service routine, respectively, and those corresponding interrupts are disabled.

When the flag bits of the same name are clear, registers k, q and u are functionally equivalent, and are for general purpose storage, counters and pointers, just like i and j. The difference is that load, add and exchange operations which target k, q and u do not affect any condition flags, making them more useful as effective-address and stack-frame pointers than w, x or y. When corresponding bits ^KQU in f are set, the registers access the BRK service routine vector, the NMI service routine vector and the system tick counter, respectively.

Registers w, x and y are functionally equivalent, and are for general purpose storage, counters and pointer arithmetic, just like i and j. Load, add and exchange operations to w, x and y affect ^NZ, similarly to the 6502's 8-bit counterparts x and y .

Register z is reset to zero at the beginning of every instruction fetch, and provides the useful constant zero (and, in certain cases, +/-1 ). Load and exchange operations to z affect ^NZ, providing a superset of the 68xx's tst instruction functionality.

I'm still struggling to flesh out the exact nature of the full-width "carry" registers, c and d, but I know I want them. More to come soon, I hope!

Mike B.


Mon Apr 06, 2020 4:08 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Interesting - more on the full width carry when you're ready!


Mon Apr 06, 2020 7:17 am
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
Thinking of modified 6502 If clear carry clears carry and sets the zero flag
then z = z & (alu==0) for all operations. You still need a way to test a loop counter
with out affecting the flags. The advantage is now flags reflect operands of any size.


Mon Apr 06, 2020 7:49 pm
Profile

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
It's not finalized yet, but my inclination is that ldc #0 should clear ^C but leave ^Z alone. Similarly, anf #-2 should clear ^C but leave c and ^Z alone.

I have several looping instructions I haven't introduced yet that don't affect flags. The most useful example is dbn #offset,reg (decrement register and branch if not equal). And there are at least five more ... but I'm getting a little ahead of myself ...

Mike B.


Mon Apr 06, 2020 8:41 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 49 posts ]  Go to page Previous  1, 2, 3, 4

Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software