CDA3101: Introduction to Computer Organization

Course Description

CDA3101 Introduction to Computer Organization is the course where a computer science student stops treating the machine as an abstraction and learns what actually happens when a program runs — how data is represented in bits, how instructions are encoded and executed, and how the processor, memory and I/O subsystems fit together.

The course is offered at approximately four Florida institutions: Florida A&M University, Florida State University, the University of Florida and the University of West Florida.

The University of West Florida places it in the College of Science and Engineering, Department of Computer Science at 3 semester hours, requires COT 3100 (discrete mathematics), and describes an "introduction to the organization and operation of a digital computer including the internal representation of data and instructions, processor design and execution along with bus and I-O subsystems and assembly language programming." The University of Florida carries it under the same title, Introduction to Computer Organization.

⚠ Florida State University runs this number as the second half of a two-course sequence, and that is the most important thing on this page. FSU titles CDA3101 Computer Organization II and requires CDA3100 Computer Organization I before it. The details and the transfer consequences are in Special Information.

Why this course exists, and why it is required in every accredited computer science degree. A programmer working in a high-level language operates several abstractions above the hardware, and most of the time that is exactly right. But the abstraction leaks constantly, and the leaks are where the hard problems live. Why is this loop ten times slower when I traverse the array the other way? Why does this floating-point comparison fail? Why does adding two positive integers produce a negative one? Why does the same code run at different speeds on two machines with the same clock rate? None of those questions can be answered from inside the abstraction. This course supplies the layer underneath.

The course starts with representation, and this is more consequential than students expect. Everything in a computer is a bit pattern, and the meaning of a pattern depends entirely on how it is interpreted. Two's complement integer representation explains overflow behaviour and why the range is asymmetric. IEEE 754 floating point explains why 0.1 + 0.2 does not equal 0.3 — which is not a bug, not a rounding display artefact, and not fixable by being careful. Character encodings, endianness and alignment follow. A large share of the mysterious bugs a working programmer meets are representation bugs, and after this course they stop being mysterious.

Assembly language is the centre of the course, and it is not taught to make you an assembly programmer. Almost nobody writes production assembly. You learn it because reading assembly is how you find out what your compiler actually did, and because writing it forces you to understand the instruction set architecture as the machine sees it: registers, addressing modes, the stack, calling conventions, how a function call really works, how a loop becomes compares and branches. MIPS is the most common teaching architecture — clean, regular, well documented — with ARM and RISC-V increasingly used, and x86-64 where the course leans toward practical systems work.

The performance material is where the course pays off most visibly. The memory hierarchy — registers, caches, main memory, disk — spans access times differing by five or six orders of magnitude, and it explains more real-world performance behaviour than any other single idea in computing. Cache locality is why row-major and column-major traversal of the same array differ by an order of magnitude, and understanding it changes how you write loops for the rest of your career. Pipelining explains why branches are expensive and why the processor guesses.

Position in the degree. This is a core, required course in every ABET-accredited computer science programme, normally taken in the sophomore or early junior year. It is the prerequisite for operating systems, computer architecture, compilers and embedded systems, and it underpins the systems half of the curriculum entirely. ⚠ Students who defer it delay the whole systems sequence, which in a four-year plan is difficult to recover from.

Learning Outcomes

Required Outcomes

• Convert between binary, decimal, hexadecimal and octal representations fluently.
• Explain and apply two's complement signed integer representation; predict overflow and explain the asymmetric range.
• Explain IEEE 754 floating-point representation, and account for precision loss, rounding, and why floating-point equality comparison is unreliable.
• Explain character encodings, endianness and data alignment, and their practical consequences.
• Perform binary arithmetic and describe how adders, multipliers and shifters are built from logic.
• Apply Boolean algebra and simplify combinational logic; construct truth tables and gate-level designs.
• Describe sequential logic elements — latches, flip-flops, registers — and the role of the clock.
• Explain instruction set architecture as the interface between hardware and software, and distinguish RISC from CISC design philosophy.
• Read and write assembly language programs using arithmetic, logic, memory access, branching and procedure calls.
• Explain addressing modes and instruction encoding formats.
• Explain the runtime stack, calling conventions, parameter passing, and stack frame construction and teardown.
• Trace the instruction execution cycle — fetch, decode, execute, memory, write-back — through a datapath.
• Explain single-cycle and multi-cycle datapath design and the role of the control unit.
• Explain pipelining, identify structural, data and control hazards, and describe forwarding and stalling as remedies.
• Explain the memory hierarchy and the principle of locality; compute effective access time.
• Explain cache organisation — direct-mapped, set-associative, fully associative — and the effects of block size, replacement policy and write policy.
• Analyse how data layout and access pattern affect performance through cache behaviour.
• Explain I/O mechanisms — polling, interrupts, DMA — and bus organisation.
• Explain and apply performance measurement: CPI, MIPS, execution time, and Amdahl's law.

Optional Outcomes

• Explain virtual memory, paging, page tables and the TLB.
• Explain instruction-level parallelism — superscalar issue, out-of-order execution, branch prediction, speculation.
• Explain multicore and multiprocessor organisation and cache coherence at an introductory level.
• Use a hardware description language (Verilog or VHDL) to specify a simple datapath component.
• Explain the compilation and linking pipeline — source to assembly to object code to executable.
• Explain SIMD and vector instructions.
• Explain power and energy considerations in processor design.
• Explain security implications of microarchitecture — side channels, speculative execution vulnerabilities.
• Explain GPU architecture and how it differs from a CPU.
• Use a simulator to measure and compare architectural configurations.

Major Topics

Required Topics

• Number systems and data representation — bases, two's complement, IEEE 754, characters, endianness, alignment.
• Computer arithmetic — addition, subtraction, multiplication, division, overflow, ALU construction.
• Digital logic — Boolean algebra, gates, combinational and sequential circuits.
• Instruction set architecture — instruction formats, addressing modes, RISC versus CISC.
• Assembly language programming — arithmetic, control flow, memory access, arrays, procedures.
• Procedure calls and the stack — calling conventions, stack frames, register saving, recursion at the machine level.
• The datapath — single-cycle and multi-cycle designs, control signals, the execution cycle.
• Pipelining — stages, throughput, hazards, forwarding, stalls, branch handling.
• Memory hierarchy — locality, levels, effective access time.
• Caches — mapping, associativity, replacement, write policies, miss classification, and the effect of program structure.
• Input/output — buses, polling, interrupts, DMA, storage.
• Performance — metrics, CPI, benchmarking, Amdahl's law.
• The hardware-software interface — compilation, assembly, linking, loading.

Optional Topics

• Virtual memory — paging, translation, TLB, protection.
• Advanced pipelining and ILP — superscalar, out-of-order, branch prediction, speculation.
• Parallelism — multicore, threads, cache coherence, memory consistency.
• Hardware description languages and simple synthesis.
• SIMD and vector processing; GPU architecture.
• Power, energy and thermal constraints; the end of Dennard scaling.
• Microarchitectural security — Spectre, Meltdown, cache side channels.
• Embedded and microcontroller architectures.
• Historical development of computer architecture.

Resources & Tools

• The standard text is Patterson and Hennessy, Computer Organization and Design: The Hardware/Software Interface — near-universal in this course, and available in MIPS, ARM and RISC-V editions. ⚠ Check which edition your section uses, because the assembly language differs between them and the exercises are not interchangeable.
• Alternatives in use: Bryant and O'Hallaron, Computer Systems: A Programmer's Perspective (x86-64, superb on the programmer-facing consequences, and the source of the widely used "bomb lab" style assignments); Null and Lobur, The Essentials of Computer Organization and Architecture; Tanenbaum, Structured Computer Organization.
• Simulators — the practical environment for most assignments: MARS and SPIM (MIPS, free, the most widely used in teaching); RARS (RISC-V); Ripes (RISC-V, with excellent datapath and cache visualisation); QtSPIM. All are free.
• Digital logic tools: Logisim Evolution (free, and the standard for gate- and datapath-level assignments), CircuitVerse (browser-based).
• Real-machine tools worth knowing early: gcc -S to see the assembly your compiler produces, objdump -d to disassemble a binary, gdb to step through at instruction level, and Compiler Explorer (godbolt.org) — free, browser-based, and genuinely the fastest way to build intuition about what high-level code compiles to.
• Reference material: the MIPS, RISC-V and ARM architecture reference manuals, all freely available; Intel's Software Developer's Manual for x86-64.
• Free supplementary courses: MIT OpenCourseWare 6.004, Berkeley CS61C (materials public), and the Nand2Tetris course and book (Nisan and Schocken) — the last is exceptional for students who want to build the whole stack from gates upward and is a genuine confidence-builder.

Career Pathways

This course is not a job qualification in itself — it is a core requirement whose absence closes doors. Systems roles in particular screen for exactly this material at interview.

• Software developers and engineers (SOC 15-1252) — the general destination. ⚠ Technical interviews at major employers routinely test this material: cache behaviour, bit manipulation, memory layout, and why one implementation outperforms another.
• Systems software engineers (SOC 15-1252) — operating systems, drivers, runtimes, compilers, database internals. This course is the entry ticket.
• Embedded systems and firmware engineers (SOC 15-1252, 17-2061) — where assembly, memory constraints and I/O are daily work rather than background.
• Computer hardware engineers (SOC 17-2061) — normally with a computer engineering degree; this course is the shared foundation.
• Performance engineers (SOC 15-1252) — profiling and optimisation, where the memory hierarchy material is directly applied.
• Security engineers and vulnerability researchers (SOC 15-1212) — reverse engineering, exploit analysis and malware work all require reading assembly. ⚠ Florida has a substantial cleared cybersecurity workforce; UWF is a National Center of Academic Excellence in Cybersecurity and hosts the Florida Cyber Range.
• Game engine and graphics programmers (SOC 15-1252) — performance-critical work where cache behaviour and SIMD matter.
• Defence and aerospace software — Florida's concentration is significant: L3Harris (Melbourne, Palm Bay), Lockheed Martin (Orlando), Northrop Grumman (Melbourne, St. Augustine), Raytheon/RTX, and the Space Coast contractor base around Kennedy Space Center — Blue Origin, SpaceX, Boeing, Jacobs. Embedded and real-time systems work is common and frequently requires a security clearance.
• Semiconductor and EDA (SOC 17-2072) — smaller in Florida than in Texas or California, but present.
• Graduate study in computer architecture, systems, compilers or security.

Special Information

⚠⚠⚠ FSU splits this course in two — the most important transfer note here

Institution	CDA3101 is…	Prerequisite
UWF	Introduction to Computer Organization — the whole introduction, including assembly	COT 3100 (discrete mathematics)
UF	Introduction to Computer Organization	—
FSU	Computer Organization II — the second course of a two-part sequence	CDA3100 Computer Organization I

FSU runs a two-course sequence. Its CDA3100 (Computer Organization I, corequisite COP3330) covers number representation, instruction set architecture, logic gates and design, datapath and control, pipeline, memory hierarchy and the execution cycle. Its CDA3101 then goes deeper into "processor design, including datapath and control, pipelining, memory hierarchies, and I/O." UWF and UF put all of that into one course.

⚠ Both directions of transfer have a problem, and they are different problems.

• Transferring INTO FSU with CDA3101 from UWF or UF: the credit articulates on the number, so FSU records CDA3101 as complete — but you will never have taken CDA3100, which is a prerequisite for other FSU courses and part of its degree requirements. You may be recorded as having the second course of a sequence whose first course you are still missing.
• Transferring OUT of FSU with CDA3101: you hold the deeper second course, which is fine — but if the receiving institution's requirement assumed the single-course version, be prepared to show that the material was covered across two courses rather than one.
• ⚠ You cannot simply take FSU's CDA3101 as a visiting or transient student without CDA3100, because the prerequisite is enforced.

What to do: keep both syllabi, and raise it with the computer science department rather than the registrar, because only the department can judge whether the material is covered. This is a sequence-position divergence — the same shape as the MUL4400 case documented elsewhere in this repository, but sharper here because FSU's prerequisite proves the position rather than merely implying it.

Prerequisites and position in the curriculum

UWF requires COT3100 (discrete mathematics). That is partly content — Boolean algebra and number bases come from there — and partly a maturity proxy, since the course's reasoning is formal.

⚠ The unstated prerequisite is programming ability, and it matters more than the listed one. The course assumes you can already program comfortably in a compiled language, ideally C or C++. FSU makes this explicit by pairing CDA3100 with COP3330 and noting that the course is "intended for computer science majors with previous C/C++ background." A student whose only experience is Python will find the pointer, memory and address material substantially harder, because Python deliberately hides exactly what this course is about. If that describes you, spend time with C before the term starts — it is the highest-return preparation available.

The course sits in the sophomore or early junior year and gates the systems sequence: operating systems, computer architecture, compilers, embedded systems. Take it on schedule.

Course format and workload

3 credits, 45 contact hours — lecture three hours per week. Some institutions attach a laboratory or recitation section; UWF's listing carries no suffix, so the assembly work is done as homework rather than in scheduled laboratory time.

⚠ Expect 9–12 hours per week outside class. This is one of the heaviest 3-credit courses in a computer science degree, and students consistently underestimate it. The reason is the assembly assignments: debugging assembly is slow, the failure modes are unhelpful (a program that produces garbage rather than an error message), and there is no framework to lean on. A project that would take an hour in Python can take eight in MIPS.

Assessment is typically programming assignments in assembly, problem sets on representation and performance, and examinations. Some sections include a datapath design project in Logisim or a hardware description language.

⚠ What students find hardest

• Assembly has no abstractions to hide behind. There are no variables, no types, no loops — only registers, memory addresses, compares and jumps. Students who have never worked without those conveniences find the first assignment disorienting rather than difficult.
• Debugging. A wrong register produces a wrong answer with no diagnostic. ⚠ Learn the simulator's single-step and register-inspection features in week one, not in week six — this single habit is the difference between students who cope and students who do not.
• The stack and calling conventions. Which registers the caller saves, which the callee saves, how arguments are passed, how the frame is built and torn down. It is fiddly, it is where most assignment bugs originate, and it is examined heavily. Draw the stack.
• Floating point. Students resist the conclusion that 0.1 + 0.2 != 0.3 is correct behaviour rather than a defect. Accepting it is the point.
• Cache mapping arithmetic. Splitting an address into tag, index and offset is mechanical once understood and baffling until then. Work several by hand.
• Breadth. The course covers logic gates through processor design through memory systems in fifteen weeks. Falling two weeks behind is very difficult to recover from, because each topic assumes the last.

Articulation and transfer

CDA3101 is a 3000-level upper-division course, not generally offered at Florida College System institutions, and taken after transfer.

The number articulates through SCNS — and, as set out above, the articulation succeeding is exactly what conceals the FSU sequence problem. This is the same failure shape this repository documents for SPN3400: when numbers match and content does not, nothing flags the mismatch, because from the system's point of view nothing went wrong.

⚠ Related numbers. CDA3100 (Computer Organization I at FSU), CDA4150 (Computer Architecture — the follow-on), CDA3103 (used for computer organisation at some institutions), COT3100 (discrete mathematics, the usual prerequisite). Check the description, not the number, when planning a transfer in this prefix.

⚠ ABET note. Computer organisation is a required component of an ABET-accredited computer science programme. If you are transferring between an accredited and a non-accredited programme, the requirement will be enforced regardless of how the credit articulates.

AI Integration

This is a course where AI assistance is genuinely useful in some places and actively counterproductive in others, and the boundary is unusually clear.

Where it helps. Language models are good at explaining a concept a second way — why two's complement is designed as it is, what a pipeline hazard is, how set-associative mapping works. They are good at generating practice problems in address decomposition or CPI calculation, which is exactly the kind of repetitive drill that builds fluency. They are reasonable at explaining an unfamiliar instruction or a line of disassembly. And they are useful for translating between architectures conceptually when your textbook edition and your simulator disagree.

⚠ Where they fail, specifically. Models are unreliable at generating correct assembly. The code they produce compiles-and-looks-right while violating calling conventions, clobbering saved registers, or mishandling the stack — and those are precisely the errors that are hardest for a beginner to find. They also confuse architectures, producing MIPS syntax with ARM semantics or inventing instructions that do not exist in the ISA you are using. And they are frequently wrong on numerical detail in cache and performance calculations, which look authoritative and are simply incorrect.

The deeper problem is specific to this course. Its entire purpose is to remove abstraction — to make you understand the layer that generated code sits on. Using a tool to generate the assembly you were asked to write reinstates exactly the abstraction the course exists to strip away, and leaves you unable to do the thing the course was for. In most courses that costs you a grade; here it costs you the ability to answer the systems questions that technical interviews are built around.

A genuinely excellent use worth adopting: Compiler Explorer (godbolt.org). Not AI, but the single best tool for this course — write C on the left, see the generated assembly on the right, change an optimisation flag and watch the output change. Then ask a model to explain what changed and why. That combination teaches the hardware-software interface faster than anything else available, and it uses the model for explanation rather than for production, which is where it is actually reliable.

Worth knowing as subject matter: AI workloads have driven the most significant architectural change in a generation — GPUs, tensor and matrix units, reduced-precision formats such as bfloat16 and FP8, and memory bandwidth as the binding constraint. Several of this course's concepts are the reason those designs look as they do, and instructors increasingly use them as the motivating example for the parallelism and memory-hierarchy material.

Academic integrity. Read the syllabus; computer science departments have generally written specific AI policies, and they vary from prohibition to structured permission. ⚠ Code plagiarism detection in this discipline is mature and effective, and assembly is unusually distinctive — register allocation choices and instruction ordering function as a fingerprint. Submitting generated assembly is both detectable and self-defeating.