CASTalk.com

Steve · Guest

Way back in 2000 or so, I did a little prototyping for an application I
was considering that led me to conclude there are certain CPU features
that might be worth adding to existing CPU designs (I'm thinking of
commodity architechtures, mostly x86 as that is the kind of system
I've had acess to in recent years) that would be potentially
interesting to use. At the outset I must admit that I have no real
technical knowledge of CPU or ASIC design, nor do I have much in the
way of assembler experience. I am influenced in this to a minor degree
by my exposure to the Amiga custom chipset and the thourough
documentation that was contained in the Amiga Hardware Reference
Manual_, first edition. As I know nearly nothing about what I am going
to describe, and because I have made certain assumptions from (probably
incorrect) infrences, I expect that my discussion here will contain
many silly errors. Plus, this is written quickly as I am rather busy,
and unfortunately have little time to devote to matters related to
computer science. Finally, my expertise in programming is largely
confined to Linux and a language which shall go unnamed but which
starts with the letter 'C'.

To start, then, I have noticed that CPU registers are rather simple.
Too simple, it seems. I struck me one day to imagine the utility of a
register that could describe a range of memory, rather than merely a
specific memory location. It is well known that there are memory
access penalties in some architectures for addresses that do not fall
on word boundaries. With the exception of character pointers and
sixteen-bit integers, in usual applications most pointer accesses are
on so-called word boundaries. On x86, this is usually a thirty-two bit
size, but now we are seeing sixty-four bit machines hitting the retail
market. For the sake of this speculative discussion I am going to
entirely ignore odd addresses and their associated problems.

So, the vast majority of address decoding in the CPU occurs in
situations where the least significant two or four bits are zero. When
we are considering page tables in the MMU, such as with 4K pages on
x86, the resolution of an address falls even further with the least
significant twelve bits of page table entry being all zero. This seems
to be a bit of a waste, as some will realise when they think of the
occasional programming and memory benefit to be had from packing bits
when space is at an extreme premium.

We all know that memcpy(1) is one of the most common idioms of
practical programming. Despite the efficiency of on-chip cache, etc.,
it seems a waste in even this simple instance to require a compiler to
include a relatively lengthly piece of code just to move one section of
memory to another. What if there were registers that could be made to
describe arbitrary ranges of memory, and which in some way were largely
integrated with the instruction set of the CPU?

Imagine that CPU registers are modified in such a way as to include a
mask that described their range:

On x86, you might have the Ax register tied to the 'Amx' mask. This
hypothetical Amx register would, in effect, describe an arbitrary
'page' size that modified the way the CPU interpreted addresses
contained in the Ax register. In effect, you would be chopping up the
Ax register in two pieces: one component of the register (probably the
most significant bits) would describe the address, and some bits to
identify the address range, or span.

Assume for the sake of argument that the 32 bit hypothetical Axm
register is divided equally into two 16-bit partitions. First is the
page size, specified in bytes, also known as the address multiplier.
Second is the number of bits of the Ax register to be allocated to
range calculations. In the normal case, the Axm register might contain
all thirty-two bits zero, indicating that the register should behave as
normal, the way one would expect in today's common architectures;
giving backwards compatibility. But let's assume that a compiler or
assembler programmer has found a use for this new functionality and
wishes to do a memcpy(1) across a range of memory. The Axm register
mask might then be loaded with a value like 0x0200080. In this case,
the interpretation of the Ax register is modified as follows:

0x0200 equates to a 1K page size.
0x0008 equates to a range size of 8 bits.
Thus, the Ax register is divided:

Ax: |xxxxxxxxxxxxxxxxxxxxxxxx|xxxxxxxx|
| address | range |

The address portion of the Ax register is unconditionally multiplied by
its 'page' size, and then covers the range specified by the eight
remaining bits, again perhaps multiplied by the local page size.

In an instruction like mmove, the destination register would, of
course, be any legal address, and would denote the starting address for
the copy. I imagine that this scheme would easily apply to comparison
instructions, and with the added compliction in a hypothetical future
architecture allowing three instruction operands, to AND, OR, XOR, NOR,
shift and rotate fuctions, and so forth. I am not going to consider
the possible validity of this scheme applied to integer math
operations, save to say that bright chip designers might fashion a
schema that meshed with such functions, as well as with other less
common assembler instruction idioms.

Clearly, in this hypothetical arrangement there are Axm mask values
which would be invalid, and as well there would be Ax register values
which would fall outside the capacity of the address bus. Presumably,
extensions to the exception or trap mechanisms would allow for input
validation and sane address decoding.

I realise that the implementation of this kind of approach to address
coding and decoding is a bit of a devilish problem. Instruction sets,
their features, coding, and modalities are tightly integrated at a
particular level of abstraction. I understand, perhaps incorrectly,
that the approach to contemporary CPU design is something of a modular
affair. I imagine that the on-chip address decoder(s) are something of
a self-contained unit that is integrated with the cache-control logic
and the MMU, and the actual address bus. The adder is something of a
standalone functional unit and only ever sees data values that have
been acquired by a whole lot of address logic pre-processing. In terms
of an instruction like mmove, I suggest that the logic that is devoted
now to the actual job of transferring data from a register or EA to
another register or EA, _might_ be extended to cover iterations over a
range without an unreasonable expenditure of chip real-estate.
Similarly, for boolean algebra primitives, this supposition could hold
true. We now have dual-core CPUs as evidence that there is no real
shortage of on-chip real estate.

Considering a technology like hyperthreading, there is a big question
of implementation. There are two broad approaches to instruction set
enhancements. Recently with Intel we have seen MMX, SSE, and SSE2
instruction set additions that appear to be bolted on to the original
CPU architecture as if they were adding a co-processor on-chip. The
other option, and the one I favour in my wild fantasies, is a tightly
coupled extension of an existing instruction set. With something like
hyperthreading, an application that is copying memory simply blocks
until it is done -- resulting in something of an atomic operation --
while other 'threads' might continue to execute, potentially contending
for the memory bus and basic functional CPU components in a manner not
entirely unlike what was seen from the Amiga's blitter and copper.
However, I realise that chances are that the practical constraints of
CPU design, and the way that I assum VHDL is used, will suggest an
entirely new CPU product.

To go futher into the wild blue yonder of ignorant speculation, I would
suggest that this kind of address and register scheme might even apply
to the general architecture of memory management as we know it. If
page tables were described similarly to registers as above, we could
have relatively arbitrary page sizes, which would be very interesting
to virtual memory systems. If practical.

This is all pretty much off the top of my head, and I am limited by my
lack of expertise in this area. I have not studied architectures other
than those offered in contemporary retail systems. I have no idea what
goes on in the world of big iron, nor what is being done with
special-purpose engines as may be found in high-end video display
processors. I wouldn't recognise a vector engine if it bit me in the
ass, and I couldn't even imagine what the PDP people created. This is
just a very sketchy outline of an approach to address decoding and
register architecture that I have not seen considered in anything I
have read to date.

I am very interested to hear what others think of this rough scheme,
and whatever else, to learn why there is apparently nothing at all
similar appearing in modern systems accessible to the layman.

Regards,

Steve

JJ · Guest

Go back to school in some fashion, brick, web, book etc. Theres lots of
free web reading if you look.

Use google groups search to search for previous "really great ideas"
but use your own terms.

For your project work learn FPGAs, Verilog or VHDL, plus compilers,
OSes etc and implement what you learn about comp arch in FPGA in a
small scale. It will probably look like a mips or dlx or microblaze. To
some extant you can upgrade those architectures with your own ideas.
Forget about hacking x86, its already the most hacked up arch that ever
existed.

Should only take a few years out of your life, seriously

johnjakson at usa dot com

Edward A. Feustel · Guest

"Steve" <steve49152@yahoo.ca> wrote in message
news:1119928828.746326.94220@f14g2000cwb.googlegroups.com...
..

Steve · Guest

Edward A. Feustel wrote:

Tom Linden · Guest

On 28 Jun 2005 18:02:19 -0700, Steve <steve49152@yahoo.ca> wrote:

Grumble · Guest

Steve wrote:

Eric P. · Guest

Steve wrote:

Jeremy Linton · Guest

x86 also supports multiple page sizes (4k, 2M, and 4M) No one uses the
2M mode, but both windows and linux use mixed pages sizes 4k and 4M. The
4M page use is very restricted.

Grumble wrote:

Rick Jones · Guest

Grumble <devnull@kma.eu.org> wrote:

John Mashey · Guest

Eric P. wrote:

Steve · Guest

Grumble wrote:

John Mashey · Guest

Steve wrote:

Jan Vorbrüggen · Guest

Steve · Guest

John Mashey wrote:

Anne & Lynn Wheeler · Guest

"John Mashey" <old_systems_guy@yahoo.com> writes:

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT Goto page 1, 2, 3, 4 Next
Page 1 of 4