Various codes have been used in computing, EBCDIC, Fieldata etc., with various bit combination’s, and total bits between 5 and 8. This often depended on which proprietary computer system you were using, and what type of device you were using. Punched cards had a different code again. A standard code, ASCII, was eventually introduced. The American Standard Code for Information Interchange has 8 bits, and is used interchangeably on almost all systems today.

PAPER TAPE CODES

Paper tape was upgraded to 8 bits across, plus the sprocket, and used to boot computers, and to transfer data from one machine to another. For instance a NC, or Numerical Control, could use paper tape to relay instructions to a machine for cutting steel sheet shapes.

PUNCH CARD CODES

Punch cards had been used since the 19th century, and a couple of different formats had emerged, round holes, rectangular holes, 80 per card, 90 per card, different codes, etc. Once again it depended on whose computer you were using IBM, Univac, Control Data etc. However, the basic principle was the same. The ‘standard’ came to be the 80-column card, with 12 rows for each character. The 1 to 9 rows were numbers 1-9, with the 0, 11 and 12 rows being used for various special characters, shifts etc.

MAGNETIC TAPE CODES

Magnetic tape, initially on 10 inch reels of half inch wide tape, 2400 ft long, used variations of the computer codes. Initially 6 bits plus parity (7) were written across the tape. With the introduction of bytes this increased to 9 bits to incorporate the 8-bit byte plus parity.

Most variations here have been in the recording system, that is how the data is written to and read from the tape. These include NRZ (Non Return to Zero), PE (Phase Enabled) and, latterly GCR (Group Controlled Recording). The density possible has increased, so that the capacity of the tapes even in the present day small cassettes has greatly increased.

Transport methods, initially ‘Stop-Start’, to record each character, now more commonly ‘Streaming’, have developed in parallel. The tape has normally been written in blocks of various lengths with codes being required to control these, such as ‘Start of Block’, ‘Start of Data’ etc. Other codes are used to verify the data. The DAT (Digital Audio Tape) tapes used today use a different form of digital coding, but data codes are much the same.

As well as the parity bit in each character, there can be a parity bit, for example, for all the ’3′ bits in a block. This is known as ‘longitudinal parity’, or parity along the tape, a bit for each ‘row’ of bits in the block. You can also have a CRC or, cyclic redundancy check, which considers all the bits in the block, in a complicated formula.

All these check codes are necessary because magnetic tape is an inherently unreliable medium, as you probably know from listening to your old cassettes! This has caused ECC or error correction codes to be developed, similar to those used in memory. In fact there are so many extra codes on the tape you wonder if there is enough room for data.

In part 3 we look at data transmission, disk, and printer codes.

Author: Tony Stockill
Article Source: EzineArticles.com
Provided by: Digital TV, HDTV, Satellite TV

In theory, it is possible to directly translate each source code statement to a sequence of microprocessor instructions which will perform the desired result. However, in practice it is better to perform the compilation in two steps. The first step is to process the source code and generate an intermediate code, and in the second step to process this code to generate the final executable code for our target microprocessor. There are many advantages in this approach.

It is a very good idea to have a target-independent intermediate code. This code is usually a description of the high-level statements with some simpler instructions that accurately represent the operations of the source code statements. This code will not execute in a real processor, it is only an internal representation of our high-level program. Since it uses simpler constructs than the high-level language it is much easier to determine the data and control flow. This is very important for optimization algorithms.

Target-independent intermediate code means that for each high-level language that needs to be supported we only have to write the first part of the compiler, the code generator is already written for the intermediate code which does not change. The same applies to the second part, the code generator. If we need to port our compiler to another platform, we only need to write a new code generator for the new processor.

The choice for intermediate code representation is not a simple task. We need to define a language that will be platform independent, will support all the features of desired processor families and will be easy to analyze for code optimizations.

Author: Igor Funa
Article Source: EzineArticles.com
Provided by: Latest trends in mobile phone