NOTE: Heritage / 1 presents an architecture (strictly) 16 bits and I have no intentions of changing it. What follows is just a reflection on the sidelines.
My "love at first sight" for the 16 bit part of: (1) the symmetry between the size of the address and data in a machine likely to be built and (2) the fact that this is the traditional size ( and comfortable) to an integer.
Perhaps in the context of a typical whole numbers do not stand out as protagonists of the action, a role that is reserved for the rational numbers (floating point). However, under the carpet, both the OS and the application itself handle a large number of structures in memory (eg arrays) whose Access is based on rates that can not only be integers. And while the machine addressable space limited to 2 ** 16 locations (and therefore any structure in memory), an unsigned 16-bit is more than reasonable.
The problem starts when I begin to consider other tasks such as handling of characters and an arithmetic decimal (BCD).
Characters (ASCII) are 8 bits, so that a fence in memory of 16 locations is not exactly the "more natural". For its part, BCD arithmetic (as opposed to a floating point) I find it very attractive for its simplicity and greater assurance of accuracy, but the numbers represent her by "nibbles" (4 bits), not "words" (16 bits).
Right now I'm making adjustments in my ALU to ensure the necessary support for this work is definitely settled by Software! However, I wonder (and that is what this discussion) if 8-bit architecture would have addressed these problems more naturally and efficiently.
In fact, I always saw Heritage / 1 as a general purpose minicomputer that is, I never sat down to imagine a specific use for it. If that is the case, I have focused on a design "optimized" for that use.
Say, for example, that the machine is designed to handle a accounting system. This involves a large number of users, reporting and handling of numbers with two or three decimal digits of precision. Thus, the emphasis should be on the peripherals (terminals, printers, storage), management of text and a simple rational arithmetic as BCD.
peripherals for teaching has taken IBM/360 "channels" (additional minicomputers optimized for input / output). Although I think my solution (peripheral buffer and "smart") not far from it.
for intensive work with characters had opted for a bus 8-bit data, a memory and records organized in Bytes also 8-bit internal. Here I had lost the symmetry direction-data; surely have made the traditional "index registers" 16-bit indirect address to which my computer would prove a "Intel 8080" giant. Perhaps
operations had been conceived in my 16-bit ALU for that whole manage efficiently, for example, memory access arrangements. In this way could provide efficient instructions for both integer and characters.
For BCD arithmetic, the hardware had been implemented. 8-bit architecture would have saved me almost half the space and the cost of the circuits, so it would plenty of room to build a strong ALU, even able to multiply and divide.
The challenge had been to codify instructions on only 8 bits. At Heritage / 1 all instructions are encoded in a single word and the operand (if any) is simpre of a word.
In an 8-bit architecture is still necessary to read 16-bit operands (for example, the address in a direct address instruction) which takes two machine cycles instead of one. An alternative solution is to access memory in terms of bytes and words, ie, wired to 16-bit CPU but allowing the access a word or a byte at a time as instructed. Is a solution inelegant, but more efficient.
short, this "machine optimized for accounting system (which does not reduce generality) would be very different Heritage / 1. Its design would not be very elegant but surely address their work more efficiently.
Following this consideration, the challenge is to get my Heritage / 1 characters get to work comfortably and BCD arithmetic implemented by software, but if it means breaking the current architecture ... [I think].
0 comments:
Post a Comment