Make A Bmx Bike Online

Eight-bit Virtual Memory versus sixteen

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].

Can You Reserve Flights

How useful is Heritage / 1 in practice? ALU-accumulator

I said that Heritage / 1 wanted to be a computer "old" but "useful." Without emgargo, and even if the hardware were to work reliably, Heritage/1presenta serious limitations even within the framework of "his age" (1966-1972).

The first limitation is the purely personal (single taxpayers) of this project, which limits the growing of software: even if I try I can not get far developing it all, from the operating system to applications, to hit assembly and without the slightest support previous code. Carrying

Open Source code is not possible at this stage since the architecture of Heritage / 1 is too early to existing Open Source code, for example, Heritage / 1 does not support Virtual Memory (which is that can be repaired in the future by building an MMU to achieve inserted into the existing architecture.) An alternative would be to port code "ancestral", but this is a technical rather than archaeological work for other hard in both directions.

Consequently, I can not make utilitarianism a central objective of the project. Rather, utilitarianism is a guide for experimentation in the field of Software. My applications are hopelessly primitive, but must (of course) be designed to work "compelling" as, for example, the database management. The ultimate goal is not to use the machine to solve day-to-day but experience with application development "real life" within the historical context of Heritage / 1 (1966-1972).

the only way to get away (as well as the minis came in the 70s) would be collaboration between hundreds of programmers over the Internet, ie converting Heritage / 1 on a collaborative project. But for that H1 should be sufficiently attractive and do not think that's the case.

The initial question can not therefore be answered with too much optimism. The machine is designed to perform useful work, but in practice will be as useful as my patience will allow.

Parts Of A Aircraft Propeller

Heritage / 1 is (or intends to be) a computer "classic", and as such uses a "cumulative" (record) that works with a typical Arithmetic Logic Unit (ALU). The latter consists of 16 purely combinational circuits whose outputs feed an internal bus called Bus Result (R-BUS).

Each of these combinational circuits has two 16-bit inputs and one output also 16 bits. Tickets are continuously fed from the internal CPU Data Bus (D-BUS) and the output of the accumulator, respectively. The output connects to the R-BUS via a third buffer state, in particular, the first of these circuits do not pass over the D-BUS to combine their output without the contents of the accu, which allows to use A as a regular registration.

logical and arithmetic instructions generate control signals for the circuit for the ALU (for example, the Addendum) opened its R-BUS output while the others remain in third state, after which it commands the tank to store the result (R-BUS).

The following block diagram of the CPU, you can see which is the interconnection between the accumulator (A) and the ALU.



Frankly, this arrangement was the first thing that came to mind, after designed, however, I have seen is not as common nor commercial computers or on personal projects like Heritage / 1. Usually (as I have seen) is to place the accumulator "before" the ALU, allowing the result of the arithmetic logical operation calculated by the same go directly to the data bus.

The following block diagram of the Intel 8085 microprocessor can be seen that type of arrangement.



The advantage is obvious: the result of a logical, arithmetic can be any record of the CPU (not just in A) which avoids having to move a step further. However, there is a price to pay: the need for a temporary register feeding the other input ALU, as shown in the figure above.

Designing Heritage / 1 has among its premises a minimum use of temporary registers and do not use either. This is in the mood to save clock cycles in the execution of the instructions, so as to simplify the circuits in question. So use a temporary register for the ALU would mean a breach of this premise.

The price to pay is the inability to save the result of an arithmetic logical operation in another record that is not A, as illustrated in the following code segment:

 
; Add contents of B and D 
; depositing the result in C 
 mov a, b 
 add a, d 
 mov c, a 
, with a different architecture, had taken 
, a single instruction: 
, add b, d, e 
 

recognize it is a limitation imposed on the programmer - I'll be myself after all! - but assume for the sake of preserving a simple hardware design where the use of temporary registers is a kind of heresy.