CPU Instruction Set Architecture

``I wisdom dwell with prudence,
and find out knowledge of witty inventions.''
-- Proverbs 8:12

As 64-Bit CPUs Alpha, SPARC, MIPS, and POWER aptly put it:

In a time when microprocessors are advertised on TV and CPU vendors have their own jingles, the fantastic technology embodied in these chips seems almost irrelevant. And it nearly is -- microprocessor marketing is drawing ever nearer to perfume advertising.

All the emphasis is on packaging and marketing, branding and pricing, channels and distribution, with little left over for solid product details, features, and benefits. Little old ladies who don't know a transistor from a tarantula know the name "Pentium" and think they want "HyperThreading." It's a good thing that for some of us, the technology still matters.

Also please don't be glamorized with the performance. Performance, which common folks associate with clock rate in MHz is a tricky thing to measure and to use and it's not all that matters in chips design.  Often price/performance ration is as important or more important. Moreover, ever for raw performance, benchmarks like SPECCPU are more relevant the clock speed. Please remember about so called "MHz myth". This is the battle that AMD used to fight in late 90th: they were spending big bucks trying to remind people that just because that P4 is running at 3GHz, it doesn't mean that it is faster than a 2.2GHz Athlon.

It's irrelevant how many times per second the chips clock says "tic-tac", what matters is how fast real chips can get real jobs done. For real-world purposes, you can compare the best (i.e., the fastest chips) or the most valuable (i.e., the ones with the best speed/price ratio).  To use a car metaphor (that most people seem to understand), not everyone needs or wants to drive a Lamborghini. It's expensive, it's hard to park, it's hard to drive, it's cramped and it drinks gas like there is no tomorrow. Most people are better off with a "normal" car, that's fast enough and powerful enough for them, is easy to drive, and has room for the kids and the dog.

There are several classic real architectures like System 3xx, SPARC, MIPS, VAX-11, PowerPC, Intel x86 and  Itanium. But real CPUs (other then MIPS) are always a little way to complex to study. Emulators of some  ideal "teaching" architectures makes a pleasant change from real system in the same way as miniOSes are a real pleasure to work with in comparison with systems with a gigabyte minimum memories requirements and kernels that no single human being can comprehend :-). Also CPU manufacturers always leaves some things out, but in an emulator you can try to correct their mistakes ;-).  There are also two important  "ideal" machines created by highly respected authors:

• DLX is an emerging academic standard and  and emulates MIPS-like architecture. It's documented in "Computer Architecture: A Quantitative Approach" by Hennessy and Patterson. The latter is the bible of CPU architecture. The reasoning in H&P is so clear and makes so much sense that I think there is little to add to what they wrote.

  DLX instruction set format:

  • 32-bit fixed length instruction with 32 general purpose registers (actually 31 as R0 has a hard-wired zero).  Memory is Big Endian byte addressable (i.e. byte 0 is in the most significant position of the word), and all instruction accesses are aligned.
  • Lots of registers (31 general purpose registers, and an always-0 R0). R31 is used as the link register for in the JAL (jump and link) instruction.
  • Three-operand, load-store architecture.  6 bits for the opcodetwo source and one destination operands encoded each in a five bit field; immediate data limited to 16 bits so we can fit it in a 32-bit instruction
  • Its major advantage is that gcc has already been ported to it, so we don't need to write a new compiler on top of everything else. You can try to port the Linux kernel to it :-). But there are other interesting things that you can do.
  • There are very few instruction formats, and they are closely related. In fact there are only three:

    I Format

    R Format

    J Format

  • Comparatively few instructions (only 64 possible opcodes) with expanding opcodes (the opcode&func fields can be considered as a 17 bit expanded opcode).
  • Few addressing modes (only immediate and displacement - their term for indexed addressing using a constant index). Loads and stores must be aligned, but there are instructions to support unaligned data.
  • No condition codes. Branches are computed by comparing a register to zero as part of the branch instruction (eg BNEZ). There are also some ``helper'' instructions that will compare two registers and place a 1 or a 0 in the destination register depending on whether the comparison comes out true.

• MMIX is Donald Knuth's project for volume 4 of  The Art of Computer Programming (TAOCP).  It has RISK instruction set that can be considered as a derivative of DLX architecture (see below). It's described at http://sunburn.stanford.edu/~knuth/mmix.html. The design goal is be easy to understand, (so as not to distract from the algorithms), but still to give readers a good general idea of how high-level constructions are actually implemented. As such was not designed to be particularly fast, low-power, cheap, or any of the other things that real CPUs need to deal with. But please note that a side-effect of being easy for humans to understand is usually a fast implementation ;-).

  MMIX  operates primarily on 64-bit words. It has 256 general-purpose 64-bit registers (too many for my taste ;-) that  can hold either fixed-point or floating-point numbers. Instructions have 4-byte form `OP X Y Z', where each of OP, X, Y, and Z is a single 8-bit byte. If OP is an ADD instruction, for example, the meaning is ``X=Y+Z''; i.e., "Set register X to the contents of register Y plus the contents of register Z.'' It has only 256 possible OP codes that fall into a dozen or so categories. 

  Again, many people, including myself, think that 256 registers are "too many" and 16 like in good old System 360 is too few :-). Section 42 describes a limited version of MMIX with only 32 local registers plus 32 global registers (plus the 32 special registers), that is binary compatible with most MMIX programs.

  The cycle counter, the interval counter, and the usage counter might by very useful for profiling.

  It is nice that "DIV" calculates both the quotient and the remainder, even though those 4 numbers (2 input, 2 output) don't fit in the general 2 input, 1 output scheme. I don't like special-purpose registers, but I hesitate to criticize the plethora of "special registers" in MMIX

  Subroutine linkage is, at first glance, unnecessarily complicated.
   
• SPARC's instruction set i s similar to MIPS but its register set is unique. SPARC exposes 32 registers at any one time, but these registers are ju st a "window" into a larger set of physical registers. The additional registers are hidden from view until you call a subroutine or other function. Where other processors would push parameters on a stack for the called routine to pop off, SPARC processors just "rotate" the register window to give the called routine a fresh set of registers. The old window and the new window can overlap, in this case some registers are shared. As long as you're careful about placing parameters in the right registers, the windows are a slick way to pass operands without using the memory stack at all. If we assume that  the register set is big (for example 4K registers), then overflow is not a  problem. In reality you need to deal with it, burning cycles.  Complexity of this register scheme are largely the reason why SPARC was never a leader in benchmarks.

NEWS CONTENTS

• 20050101 : The year in microprocessors ( The year in microprocessors, Jan 1, 2005 )
• 20050101 : 64-bit Futures Part III - IBM and Sun ( 64-bit Futures Part III - IBM and Sun, )
• 20050101 : Why 64-bits are good, and why theyre not ( Why 64-bits are good, and why they're not, )

Old News

[Jan 1, 2005] The year in microprocessors

64-bit Futures Part III - IBM and Sun

Well, Power architecture is increasingly going head-on against Itanium in many large deals, even sinking the good ship Itanic in some situations with - believe or not - lower prices! And improved performance with better compilers, more superdense high-bandwidth machine like the superb p655+, where two 8-way single MCM systems with 1.7+ GHz POWER4+ processors fit within a 4U space! So, 16 systems and some 880+ GFLOPs of peak 64-bit power get squeezed into a single rack - 4 times the density of HP Itanium2! Put a nice shared-memory interconnect like the increasingly popular Bristol product, Quadrics QsNet, and you got a nasty supercomputing monster.

And, these can run 64-bit Linux (almost) as well as their home OS, AIX.

The memory bandwidth of each eight-way box is 51.2 GB/s, or eight times that of a four-way Intel Itanium2, or 11 times that of a four-way Sun USIII box. Of course, Rmax (the obtainable percentage of FLOPS in Linpack FP bench) is right now far less on Power4 than on Itanium2 - 60% vs almost 90% - but the extra frequency and greater memory bandwidth more than make up for that in many apps.

Towards the end of the year, the multithreaded POWER5 will also dramatically improve the FP benchmark scores, not to mention twice the CPU density, a quarter larger cache, even higher memory bandwidth and lower latency. But don't expect major clock speed improvements, the focus was on real performance and reliability benefits - as if chip-kill memory, eLiza self-healing, and per-CPU logical partitioning was not enough...

Finally, the existing SuSE and coming RedHat Linux on POWER4 and its follow-ons, natively 64-bit of course, aim to give extra legitimacy to it being "an open platform" at least as much as Itanium is.

On the low-end, the PowerPC 970 - or POWER4 Lite, might (or pretty much will be now that Motorola G5 is down the drain) the basis of Apple's next generation Mac platform - it's 64-bit ticket to the future. With its low power - down to less than 16W in low-power mobile 1.2 GHz mode, it will also enable very dense server blades and of course POWERful 64-bit ThinkPads or PowerBooks running AIX, Linux or MacOS...

For IBM then, Opteron makes sense as an excellent tool to corner Intel, with POWER on high end and Opteron on low-end, both 64-bit and both soon manufactured by IBM Microelectronics? No, I didn't say both owned by IBM, even though that is a possibility: AMD does need a sugar daddy, not a sugar mommy. Got my hint who the feisty "sugar mommy" could be?

What about the other major vendor, from SUN-ny California? Well, UltraSPARCIIIi is finally out, no surprise there, it helps a bit but is still far behind all other major CPUs (except MIPS) in most benchmarks. Yes, Sun's mantra of something like "we don't care about speed, we focus on our brand etc" can continue, but what is computing if not about speed and performance?

Still no sign of US IV anyway, and even when it comes, don't expect much of extra per-thread performance over US III - When (and if) it really rolls out in volumes towards yearend, it will have to fight both POWER5 and Madison2, both very powerful beasts on the rise, backed by humungous ruthless megacompanies - each of which can eat Sun as an appetiser.

You can read hundreds of pages of Net discussions about the particular merits and demerits of SPARC vs other architectures, from all sides and viewpoints, but the fact remains - SPARC is the turtle of the 64-bit world, slow and maybe long-lived compared to, say, Alpha, but even turtles have to die at some point... and before they die, they become extremely slow...

64-bit Opteron is fast in some things compared to the rest of the gang, and not so fast in others, but whatever the case, current and future Opterons are vastly superior performance and feature wise to low-end and midrange SPARC offerings at umpteen times lower cost. Plus, they are as 64-bit as SPARC (or any other 64-bit CPU) is... so Sun taking Opteron would be simply common sense...

Why 64-bits are good, and why they're not

THIS ARTICLE hopes to cast some light on why 64-bit addressing, that is, the native mode of the Opteron or Itanium versus that of the Athlon or Pentium is important in 2003. It also attempts to address what the requirements are and - equally importantly - are not.

Before we start, an easy one. Why 64-bit and not 48-bit? Because it costs little more to extend a 32-bit ISA to 64-bit than to only 48-bit, and most people like powers of two. In practice, many of the hardware and operating system interfaces will be less than 64 bits, sometimes as few as 40 bits, but the application interfaces (i.e. the ones the programmers and users will see) will all be 64-bit.

There are several non-reasons quoted on the Internet; one is as arithmetic performance. 64-bit addressing does not change floating-point, and is associated with 64-bit integer arithmetic; while it is easy to implement 32-bit addressing with 64-bit arithmetic or vice versa, current designs don't. Obviously 64-bit makes arithmetic on large integers faster, but who cares? Well, the answer turns out to be anyone who uses RSA-style public key cryptography, such as SSH/SSL, and almost nobody else.

On closer inspection, such use is dominated by one operation (NxN->2N multiplication), and that is embedded in a very small number of places, usually specialist library functions. While moving from 32 to 64 bits does speed this up, it doesn't help any more than adding a special instruction to SSE2 would. Or any less, for that matter. So faster arithmetic is a nice bonus, but not a reason for the change.

File pointers are integers, so you can access only 4GB files with 32 bits, right? Wrong. File pointers are structures on many systems, and files of more than than 4GB have been supported for years on a good many 32-bit systems. Operations on file pointers are usually well localised and are normally just addition, subtraction and comparison anyway. Yes, going to 64-bits makes handling large files in some programs a bit easier, but it isn't critical.

Let's consider the most common argument against 64-bit: compatibility.

Almost all RISC/Unix systems support old 32-bit applications on 64-bit systems, as did IBM on MVS/ESA, and there is a lot of experience on how to do it almost painlessly for users and even programmers.

Microsoft has a slightly harder time because of its less clean interfaces, but it is a solved problem and has been for several decades.

Now let's get onto some better arguments for 64-bit. One is that more than 4GB of physical memory is needed to support many active, large processes and memory map many, large files - without paging the system to death. This is true, but it is not a good argument for 64-bit addressing. The technique that Intel and Microsoft call PAE (Physical Address Extension) allows 64 GB of physical memory but each process can address only 4GB. For most sites in 2003, 64GB is enough to be getting on with.

IBM used this technique in MVS, and it worked very well indeed for transaction servers, interactive workloads, databases, file servers and so on. Most memory mapped file interfaces have the concept of a window on the file that is mapped into the process's address space - PAE can reduce the cost of a window remapping from that of a disk transfer (milliseconds) to that of a simple system call (microseconds). So this is a rather weak reason for going to 64-bit addressing, though it is a good one for getting away from simple 32-bit.

Now, let's consider the second most common argument against 64-bit: efficiency. Doubling the space needed for pointers increases the cache size and bandwidth requirements, but misses the point that efficiency is nowadays limited far more by latency than bandwidth, and the latency is the same. Yes, there was a time when the extra space needed for 64-bit addresses was a major matter, but that time is past, except perhaps for embedded systems.

So 64-bit addressing is unnecessary but harmless except on supercomputers? Well, not quite. There are some good reasons, but they are not the ones usually quoted on the Internet or in marketing blurb.

The first requirement is for supporting shared memory applications (using, say, OpenMP or POSIX threads) on medium or large shared memory systems. For example, a Web or database server might run 256 threads on 16 CPUs and 32GB. This wouldn't be a problem if each thread had its own memory, but the whole point of the shared memory programming model is that every thread can access all of the program's global data. So each thread needs to be able to access, say, 16GB - which means that 32-bit is just not enough.

A more subtle point concerns memory layout. An application that needs 3GB of workspace might need it on the stack, on the main heap (data segment), in a shared memory segment or in memory set aside for I/O buffers. The problem is that the location of those various areas is often fixed when the program is loaded, so the user will have to specify them carefully in 32-bit systems to ensure that there is enough free space in the right segment for when the program needs its 3GB.

Unfortunately, this choice of where to put the data is often made by the compiler or library, and it is not always easy to find out what they do. Also, consider the problem of an administrator tuning a system for multiple programs with different characteristics. Perhaps worst is the case of a large application that works in phases, each of which may want 2GB in a different place, though it never needs more than 3 GB at any one time. 64-bit eliminates this problem.

To put the above into a commercial perspective, almost all general purpose computer vendors make most of their profit (as distinct from turnover) by selling servers and not workstations. 64-bit addressing has been critical for some users of large servers for several years now, and has been beneficial to most of them. In 2003, 64-bit is needed by some users of medium sized servers and useful to most; by 2005, that statement could be changed to say `small' instead of 'medium sized'. That is why all of the mainframe and RISC/Unix vendors moved to 64-bit addressing some time ago, and that is why Intel and AMD are following.

On the other hand, if you are interested primarily in ordinary, single user workstations, what does 64-bit addressing give you today? The answer is precious little. The needs of workstations have nothing to do with the matter, and the move to 64-bit is being driven by server requirements. µ

Nick Maclaren has extensive experience of computing platforms

Linux.com - Ultra DMA 66. See also

• Linuxnewbie.org: Getting UDMA66 To Work(Jan 11, 2000)
  Promise PDC20262 Ultra DMA/66 supported.(Apr 25, 1999)

WWW Computer Architecture Home Page[July 7, 1999]

Tutorials

• DAV's Endian FAQ

• Index of -class-ee282h-handouts

  • Lecture 4- ISA Examples ISA case studies

  • Lecture 5- ISA Implementation Basic Pipelining

• PRINCIPLES OF COMPUTER ARCHITECTURE

Lectures and courses

• Professor Paterson. CS 252 - Graduate Computer Architecture - Spring 2001

• Dr. Peiyi Tang, Department of Computer Science, UALR
• CDA-5155 Home Page Tentative Lecture Plan

  Date	Lecture	Class Notes	PDF (2slides)	PDF (6 slides)
  08/24	Introduction and overview of the course	lect01.ppt	lect01_2.pdf	lect01_6.pdf
  08/29	Technology and application trends; performance evaluation	lect02.ppt	lect02_2.pdf	lect02_6.pdf
  08/31	Quantitative principles of computer design	lect02.ppt
  09/05	Instruction set architectures; memory addressing	isa.ppt	isa_2.pdf	isa_6.pdf
  09/07	Role of compiler technologies	isa2.ppt	isa2_2.pdf	isa2_6.pdf
  09/12	DLX architecture	dlx.ppt	dlx_2.pdf	dlx_6.pdf
  09/14	Introduction to pipelining	pipeline.ppt	pipeline_2.pdf	pipeline_6.pdf
  09/19	Pipelining hazards	hazards.ppt	hazards_2.pdf	hazards_6.pdf
  09/21	Exceptions and FP pipelines	exceptions.ppt	exceptions_2.pdf	exceptions_6.pdf
  09/26	Instruction level parallelism; dynamic scheduling	ilp.ppt	ilp_2.pdf	ilp_6.pdf
  09/28	Tomasulo's algorithm	ilp2.ppt
  10/03	Compiler support for parallelism	ilp3.ppt
  10/05	Hardware support for parallelism	ilp4.ppt
  10/10	Studies of ILP and Midterm review	ilp4.ppt
  10/12	MIDTERM
  10/17	Memory hierarchies	memory
  10/19	Reducing cache miss rates	miss rate
  10/24	Reducing cache miss penalty and hit time	cache_optimization
  10/26	Main memory	main memory
  10/31	Virtual memory	virtual memory
  11/02	Storage devices and buses	storage devices
  11/07	Metrics and performance of I/O	io-queuing
  11/09	I/O benchmarks	io-benchmarks
  11/14	Unix file system	io-unixfs
  11/16	Interconnection networks	networks
  11/21	Switching and commercial networks	switching
  11/23	Thanksgiving
  11/28	Multiprocessor architectures	multiprocessors
  11/30	Memory consistency	consistency
  12/05	Final review and course evaluation	goodbye-CA

• Computer Architecture (Graduate)

  • Class slide: Chapter 2

  • Class slide: Chapter 3
  • Class slide: Chapter 4
    

• Introduction to Hardware

  Hardware fundamentals. Lecture notes, interactive tests, and links to related materials. By Brian Brown, Central Institute of Technology, New Zealand.

• COMP465 Computer System Support

  • Floppy Disk Drive Notes

  • Hard Disk Drive Notes

  • FAT and File Notes

  • Sound Cards and CD-ROMs

  • Video Cards .

  • Serial Interfaces

  • ATA FAQ Part 1

  • ATA FAQ Part 2

  • CD ROM FAQ Part 1

  • CD ROM FAQ Part 2
    

• Principles of Computer Architecture - online introduction-level text on computer architecture for classroom testing. Includes solutions to all problems.
  
• Computer Architecture and Engineering - UC-Berkeley
  
• WSAD4 CSAA Course Notes -- IA64 architecture
  
• Architecture -- online course
• Computer Architecture
• LSU EE 4720 Computer Architecture - Lecture Slides --good
• MACS 582a Advanced Computer Architecture
• ECE-C411 Computer Hardware
• WinDLX Tutorial
• CS 322 Lecture Notes (Spring 1998) -- looks more like a decent OS course
• Tep's Web Based Courses
• Selected On-line Class Notes
• University College Computer Studies B05 notes
• 95.102 Course Notes
• Assembly Language Programming and Computer Architecture by Joe Carthy
• US Berkeley Spring 1998 [Old] CS152 Main Page by Bob Brodersen (contains lecture notes)
• Web Directory- Computer Architecture
• COMP 525 Course Home Page
  • Lecture Notes
• Computer Architecture s Changing Definition - slides http://www.cs.rutgers.edu/~hedrick/tsld045.htm
• Computer Architecture - Computer Architecture Course Notes, CA406 University of Western Australia. Useful lecture notes
• 8086 - PC Webopaedia Definition and Links - This page describes the term '8086' and lists other pages on the Web where you can find additional information. http://www.pcwebopaedia.com/8086.htm

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Open Directory - Computers Hardware
• CPU Design HOW-TO by Al Dev (Alavoor Vasudevan) many useful links on CPU design (both commercial and free; both historical and theoretical)
• SPARC International, Inc. SPARC International was created in 1989 as an independent, non-profit organization to oversee and guide the SPARC evolution.

  Our IP consists of the SPARC Instruction Set Architecture, SPARC trademarks, and, SPARC derivative TM's. The organization is funded entirely by our members in support of SPARC architecture and it's Open Standards technology.

  SPARC International fosters innovation of SPARC by offering testing and branding programs, and, by promoting and protecting SPARC and SPARC-related brand names. The organization maintains this openly and cooperatively defined technology by using it's membership fees to ensure that SPARC maintains continuity with the industry standards of binary compatibility. It is this organizations sole responsibility to clarify these definitions which are made available for free download from our web site sparc.org/resource.htm. You do not have to be a member to download. However, becoming a member provides your company the choice to test and brand products based on the SPARC architecture.

  Today, SPARC is one of the foundation architectures in the computer industry with SPARC trademarks registered in over 160 countries worldwide. SPARC architecture proved to be the most widely accepted technology for systems in the financial, academic, industrial, mission critical, and certainly the Internet market. SPARC is the logical choice for demanding, embedded applications simply because SPARC development environments streamlined the creation of complex designs on short time lines. With more than two million developers and over 30,000 applications, the SPARC community ranks among the world's largest while SPARC definitions continuously demonstrate the exceptional versatility of this open architecture.

  We encourage inquiries from college professors and university students learning the SPARC architecture definitions. Contact [email protected].

• http://www.estec.esa.nl/wsmwww/leon/ see also Gaisler Research

  The LEON core is a SPARC* compatible integer unit developed for future space missions. It has been implemented as a highly configurable, synthesisable VHDL model. To promote the SPARC standard and enable development of system-on-a-chip (SOC) devices using SPARC cores, the European Space Agency is making the full source code freely available under the GNU LGPL license.

  The LEON core has been extensively tested against the SPARC V8 architecture manual and the IEEE-P1754 (SPARC) standard, but have not been formally tested and certified by SPARC international as being SPARC V8 compliant. ...

  DO YOU WANT TO HELP? If you wish to contribute to LEON and work on (or donate) any of these modules, please Jiri Gaisler.

• WWW Computer Architecture Home Page
• Linux Hardware.net
• Links from the Intel Secrets home page
• CPU Review -- very good
• Tom's Hardware Guide -- good. Contains some interesting articles
• Linux kernel compilation benchmarks
• CPU Info Center
• Anand's Hardware Tech Page
• Chip directory
• Building the Perfect Box: How to Design Your Linux Workstation - by Eric Raymond.
• jaZip for Linux - a program for maintaing your Iomega Zip and/or Jaz drive(s) and disks under Linux.
• David Campbell's Linux / ZIP Drive Page - download drivers and read info related to getting Iomega ZIP drives to cooperate with the Linux OS.
• When two heads are not better than one...
• Jay Moon's Classes Computer Architecture
  • MIT 6.823
  • Wisc ECE752
  • Stanford EE282
  • Stanford EE482
  • Stanford EE382, Flynn
  • Berkeley CS152
  • Berkeley CS252, Patterson
  • UWashington CS548, Eggers
  • UWashington CS586, Baer
  • H&P Computer Architecture Book Home
  • P&H Computer Organization Book Home
  • DLX Software

Reference

• CPU Info Center -- good
• The PC Technology Guide
• Timeline of Microcomputers
• Introduction to MMX(tm) Technology Tutorial
• Pentium(R) Pro Processor Microarchitecture Overview Tutorial

DLX

• The DLX Architecture[PDF]
• DLX Architecture
• Pipelines in DLX
• DLX simulator http://www.cc.gatech.edu/gvu/people/student/Reid.Harmon/superdlx/
• DLX simulator http://everest.ee.umn.edu/mcerg/fast-dlx/
• gcc for the DLX http://spectra.eng.hawaii.edu/~tep/EE461/dlxman/dlxcc.html
• gcc for the DLX http://everest.ee.umn.edu/mcerg/gcc-dlx.html
• Dlxos -- a simple Os for DLX architecture
• The DLX tools accompanying The Designer's Guide to VHDL, 2nd Edition, allow you to prepare programs for execution using the DLX instruction set interpreter models described in the case study in Chapter 15 and the file-loaded memory model described in Section 18.2. The software was developed by David Knight at Adelaide University, South Australia, and is Copyright Adelaide University. Permission is granted to use the software for educational and non-commercial use.

  The DLX tools consist of the following programs:

  • dasm - an assembler that generates relocatable and absolute object files,
  • dlnk - a linker that combines separately assembled relocatable object files into a single relocatable object file and
  • dloc - a locater that converts a relocatable object file into an absolute object file ready for loading and executing by a DLX processor.
  Information on using the tools can be found in the DLX Tools Guide document provided as a PDF file with the software. The document describes the DLX assembler language, the commands used to invoke the tools, and the file formats they use. You can download archives contain the executable programs:
  • dlx-tools-linux.tar.gz in compressed tar format for Linux
  • dlx-tools-win32.zip in ZIP format for Windows

• Encoding the ISA Role of the Compiler Typical Modern Compiler

  On the following URL, you'll find a DLX machine description file
  for gcc 2.7.X:

  http://www-mount.ee.umn.edu/operator/okeefe/mcerg/gcc-dlx.html
  

  Port of dlx (emulators)

  FreshPorts -- emulators-dlx

  The Performance Impact of Flexibility in the Stanford FLASH Multiprocesso

MMIX

• Knuth MMIX MMIX 2009 a RISC computer for the third millennium
• "Introduction to MMIX" http://sunburn.stanford.edu/~knuth/mmix.ps.gz has detailed preliminary information.
• MMIXware: A RISC Computer for the Third Millennium_ book by Donald E. Knuth (Heidelberg: Springer-Verlag, 1999) http://www-cs-faculty.stanford.edu/~knuth/mmixware.html includes ``a full implementation of IEEE standard floating point arithmetic is developed in terms of 32-bit integer arithmetic, including new routines for floating point input and output that deliver the maximum possible accuracy.''

Random Findings

Disk Subsystem

• Linux/etc Hard drive madness part 1 of 2 -- good article on ATA
• Linux/etc Hard drive madness part 2 of 2 -- on SCSI
• The BIOS IDE Harddisk Limitations
• Storage Devices

• Ultra-DMA mini-HOWTO

• ZIP Drive mini-HOWTO

• Partition mini-HOWTO

Serial Communication

• Serial Communications -- from FreeBSD textbook

• Serial ports and multiport cards

• Serial HOWTO

• Serial Programming HOWTO

• Linux Parallel Port Home Page

• The Linux SCSI HOWTO

• HOWTO Multi Disk System Tuning

Parallel Port

External Parallel Port devices and Linux - Links to External Parallel Port projects and documentation.

Ethernet

• Linux and 3Com 3c5903c900 series

• Linux and the Intel EtherExpress Pro 100B

• 100Mbs Ethernet Technology Page

• Sangoma Page ; WAN Cards Frame Relay - X.25 - BSC - HDLC - SDLC - POS ; Routers Gateways APIs

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: February 28, 2019