From Newsgroup: comp.arch

On 2025-08-23 2:25 p.m., MitchAlsup wrote:

Robert Finch <robfi680@gmail.com> posted:
<snip>

My current design fuses a max of one memory op into instructions instead
of having a load followed by the instruction (or an instruction followed
by a store). Address mode available without adding instruction words are
Rn, (Rn), (Rn)+, -(Rn). After that 32-bit instruction words are added to
support 32 and 64-bit displacements or addresses.

The instructions with the extra displacement words are larger but there
are fewer instructions to execute.
LOAD Rd,[Rb+Disp16]
ADD Rd,Ra,Rd
Requiring two instruction words, and executing as two instructions, gets
replaced with:
ADD Rd,Ra,[Rb+Disp32]
Which also takes two instruction words, but only one instruction.

I have been using the term "instruction-specifier" for the first word of
an instruction, and "instruction" for all of the words of an instruction. Instruction-specifier contains everything about the instruction except
for the constants.

Since you and I are the only "RISCs" with VLE we (WE) should get our terminology aligned.

I will keep that in mind. Reminds me of compiler terminology, specifiers
and declarators.

I have scrapped the latest architecture. Independent load and store instructions look better.

I have been working on an OS implemented for the 68k primarily because
the core is reasonably stable. It can be ported to the latest ISA at a
later date.

Immediate operands and memory operands are routed according to two
two-bit routing fields. I may be able to compress this to a single
three-bit field.

Typical instruction encoding:
ADD: oooooo ss xx ii ww mmm rrrrr rrrrr ddddd
oooooo: is the opcode
ss: is the operation size
xx: is two extra opcode bits
ii: indicates which register field represents an immediate value
ww: indicates which register field is a memory operand
mmm: is the addressing mode, similar to a 68k
rrrrr: source register spec (or 4+ bit immediate)
ddddd: destination register spec (or 4+ bit immediate)

A 36-bit opcode would work great, allowing operand sign control.

I cam to the same realization ...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

The only thing in this corner of my ISA I regret is not having more bits for the scale {to cover complex double, and Quaternions}

There is a bit of inconvenience, but strenght reduction can go a
long way to bridge that gap. Consider something like

void foo (__complex double *c, double *d, long int n)
{
for (long int i=0; i<n; i++)
c[i] += d[i];
}

Wondering why "c[i] += d[i];" did not get a type mismatch.

Should be "c[i].real += d[i];"

which could be something like (translated by hand, so errors
are likely)

foo:
ble0 r3,.L_end
mov r4,#0
sll r3,r3,#3
vec r5,{}
ldd r6,[r2,r4,0]
ldd r7,[r1,r4<<2,0]
fadd r7,r7,r6
std r7,[r1,r4<<2,0]
loop1 ne,r4,#4,r3
.L_end:
ret

which is as close to optimum (just a single sll instruction) as
not to matter.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

The only thing in this corner of my ISA I regret is not having more bits >> > for the scale {to cover complex double, and Quaternions}

There is a bit of inconvenience, but strenght reduction can go a
long way to bridge that gap. Consider something like

void foo (__complex double *c, double *d, long int n)
{
for (long int i=0; i<n; i++)
c[i] += d[i];
}

Wondering why "c[i] += d[i];" did not get a type mismatch.

Should be "c[i].real += d[i];"

C's implicit conversion rules.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2