DOCSLIB.ORG

Assembly Languages Assembly Languages Assembly Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Assembly Languages Assembly Languages Assembly Language Assembly Languages Assembly Language Model One step up from machine . Assembly Languages language . Originally a more add r1,r2 COMS W4995-02 user-friendly way to program sub r2,r3 Prof. Stephen A. Edwards Now mostly a compiler target cmp r3,r4 Fall 2002 Model of computation: PC ! bne I1 ALU $ Registers $ Memory Columbia University stored program computer sub r4,1 Department of Computer Science I1: jmp I3 . Assembly Language Instructions Types of Opcodes Operands Arithmetic, logical Built from two pieces: Each operand taken from a particular addressing mode: • add, sub, mult Examples: add R1, R3, 3 • and, or • Cmp Register add r1, r2, r3 Opcode Operands Memory load/store Immediate add r1, r2, 10 What to do with the data Where to get the data • ld, st Indirect mov r1, (r2) Control transfer Offset mov r1, 10(r3) • jmp PC Relative beq 100 • bne Reflect processor data pathways Complex • movs Types of Assembly Languages CISC Assembly Language RISC Assembly Language Assembly language closely tied to processor architecture Developed when people wrote assembly language Response to growing use of compilers At least four main types: Complicated, often specialized instructions with many Easier-to-target, uniform instruction sets effects CISC: Complex Instruction-Set Computer “Make the most common operations as fast as possible” Examples from x86 architecture RISC: Reduced Instruction-Set Computer Load-store architecture: • String move DSP: Digital Signal Processor • Arithmetic only performed on registers • Procedure enter, leave VLIW: Very Long Instruction Word • Memory load/store instructions for memory-register Many, complicated addressing modes transfers So complicated, often executed by a little program (microcode) Designed to be pipelined Examples: Intel x86, 68000, PDP-11 Examples: SPARC, MIPS, HP-PA, PowerPC DSP Assembly Language VLIW Assembly Language Example: Euclid's Algorithm Digital signal processors designed specifically for signal Response to growing desire for instruction-level int gcd(int m, int n) processing algorithms parallelism { Lots of regular arithmetic on vectors Using more transistors cheaper than running them faster int r; while ((r = m % n) != 0) { Many parallel ALUs Often written by hand m = n; Objective: keep them all busy all the time Irregular architectures to save power, area n = r; Heavily pipelined } Substantial instruction-level parallelism More regular instruction set return n; Examples: TI 320, Motorola 56000, Analog Devices } Very difficult to program by hand Looks like parallel RISC instructions Examples: Itanium, TI 320C6000 i386 Programmer's Model Euclid on the i386 Euclid on the i386 .file "euclid.c" # Boilerplate 31 0 15 0 .version "01.01" .file "euclid.c" gcc2 compiled.: .version "01.01" eax Mostly cs Code segment gcc2 compiled.: .text # Executable Stack Before Call ebx General- ds Data segment .text n 8(%esp) .align 4 # Start on 16-byte boundary .align 4 ecx Purpose- ss Stack segment .globl gcd # Make “gcd” linker-visible m 4(%esp) .globl gcd %esp! R. A. 0(%esp) edx Registers es Extra segment .type gcd,@function .type gcd,@function gcd: fs Data segment gcd: Stack After Entry esi Source index pushl %ebp pushl %ebp gs Data segment n 12(%ebp) edi Destination index movl %esp,%ebp movl %esp,%ebp pushl %ebx m 8(%ebp) ebp Base pointer pushl %ebx R. A. 4(%ebp) movl 8(%ebp),%eax movl 8(%ebp),%eax ! esp Stack pointer %ebp old ebp 0(%ebp) movl 12(%ebp),%ecx movl 12(%ebp),%ecx ! − jmp .L6 %esp old ebx 4(%ebp) eflags Status word jmp .L6 .p2align 4,,7 .p2align 4,,7 eip Instruction Pointer Euclid in the i386 Euclid on the i386 SPARC Programmer's Model jmp .L6 # Jump to local label .L6 jmp .L6 .p2align 4,,7 # Skip ≤ 7 bytes to a multiple of 16 .p2align 4,,7 31 0 31 0 .L4: .L4: r0 Always 0 r24/i0 Input Registers movl %ecx,%eax movl %ecx,%eax # m = n . r1 Global Registers . movl %ebx,%ecx movl %ebx,%ecx # n = r . .L6: .L6: . r30/i6 Frame Pointer cltd # Sign-extend eax to edx:eax cltd r7 r31/i7 Return Address idivl %ecx # Compute edx:eax = ecx idivl %ecx r8/o0 Output Registers movl %edx,%ebx movl %edx,%ebx . PSW Status Word testl %edx,%edx testl %edx,%edx # AND of edx and edx jne .L4 jne .L4 # branch if edx was 6= 0 r14/o6 Stack Pointer PC Program Counter movl %ecx,%eax movl %ecx,%eax # Return n r15/o7 nPC Next PC movl -4(%ebp),%ebx movl -4(%ebp),%ebx r16/l0 Local Registers leave leave # Move ebp to esp, pop ebp . ret ret # Pop return address and branch . r23/l7 SPARC Register Windows Euclid on the SPARC Euclid on the SPARC .file "euclid.c" # Boilerplate mov %i0, %o1 r8/o0. gcc2 compiled.: b .LL3 mov %i1, %i0 The output registers of r15/o7 .global .rem # make .rem linker-visible r16/l0. .section ".text" # Executable code .LL5: the calling procedure . r23/l7 .align 4 mov %o0, %i0 # n = r become the inputs to r8/o0. r24/i0. .global gcd # make gcd linker-visible .LL3: . mov %o1, %o0 # Compute the remainder of the called procedure r15/o7 r31/i7 .type gcd, #function call .rem, 0 # m = n, result in o0 r16/l0. .proc 04 The global registers . mov %i0, %o1 r23/l7 gcd: remain unchanged save %sp, -112, %sp r8/o0. r24/i0. # Next window, move SP . cmp %o0, 0 The local registers are r15/o7 r31/i7 bne .LL5 mov %i0, %o1 # Move m into o1 r16/l0. mov %i0, %o1 # m = n (always executed) not visible across . b .LL3 # Unconditional branch ret # Return (actually jmp i7 + 8) procedures r23/l7 mov %i1, %i0 # Move n into i0 r24/i0. restore # Restore previous window . r31/i7 Digital Signal Processor Apps. Embedded Processor Conventional DSP Architecture Requirements Low-cost embedded systems Harvard architecture Inexpensive with small area and volume • Separate data memory/bus and program memory/bus • Modems, cellular telephones, disk drives, printers Deterministic interrupt service routine latency • Three reads and one or two writes per instruction cycle High-throughput applications Low power: ≈50 mW (TMS320C54x uses 0.36 µA/MIPS) Deterministic interrupt service routine latency • Halftoning, base stations, 3-D sonar, tomography Multiply-accumulate in single instruction cycle Special addressing modes supported in hardware PC based multimedia • Modulo addressing for circular buffers for FIR filters • Compression/decompression of audio, graphics, video • Bit-reversed addressing for fast Fourier transforms Instructions to keep the pipeline (3-4 stages) full • Zero-overhead looping (one pipeline flush to set up) • Delayed branches Conventional DSPs Conventional DSPs Example Fixed-Point Floating-Point Market share: 95% fixed-point, 5% floating-point Finite Impulse Response filter (FIR) Cost/Unit $5–$79 $5–$381 Each processor comes in dozens of configurations Can be used for lowpass, highpass, bandpass, etc. Architecture Accumulator load-store • Data and program memory size Basic DSP operation Registers 2–4 data, 8 address 8–16 data, 8–16 address • Peripherals: A/D, D/A, serial, parallel ports, timers For each sample, computes Data Words 16 or 24 bit 32 bit Chip Memory 2–64K data+program 8–64K data+program Drawbacks k = Address Space 16–128K data 16M–4G data • No byte addressing (needed for image and video) yn X aixn+i 16–64K program 16M–4G program i=0 • Limited on-chip memory Compilers Bad C Better C, C++ where Examples TI TMS320C5x TI TMS320C3x • Limited addressable memory on most fixed-point Motorola 56000 Analog Devices SHARC DSPs a0; : : : ; ak are filter coffecients, • Non-standard C extensions to support fixed-point data xn is the nth input sample, yn is the nth output sample. 56000 Programmer's Model 56001 Memory Spaces 56001 Address Generation 55 4847 2423 0 15 0 Three memory regions, each 64K: Addresses come from pointer register r0 . r7 x1 x0 Source Program Counter y1 y0 Registers Status Register • 24-bit Program memory a2 a1 a0 Accumulator Loop Address Offset registers n0 . n7 can be added to pointer b2 b1 b0 Accumulator Loop Count • 24-bit X data memory Modifier registers cause the address to wrap around 15. PC Stack 15 0 15 0 15 0 . • r7 n7 m7 24-bit Y data memory Zero modifier causes reverse-carry arithmetic . 0 . Idea: enable simultaneous access of program, sample, Address Notation Next value of r0 r4 n4 m4 Address 15. SR Stack r3 n3 m3 . r0 (r0) r0 . Registers and coefficient memory . 0 r0 + n0 (r0+n0) r0 r0 n0 m0 Stack pointer Three on-chip memory spaces can be used this way r0 (r0)+ (r0 + 1) mod m0 r0 - 1 -(r0) r0 - 1 mod m0 One off-chip memory pathway connected to all three r0 (r0)- (r0 - 1) mod m0 memory spaces r0 (r0)+n0 (r0 + n0) mod m0 Only one off-chip access per cycle maximum r0 (r0)-n0 (r0 - n0) mod m0 FIR Filter in 56001 FIR Filter in 56001 TI TMS320C6000 VLIW DSP n equ 20 # Define symbolic constants movep y:input, x:(r0) # Load sample into memory start equ $40 # Clear accumulator A Eight instruction units dispatched by one very long samples equ $0 # Load a sample into x0 instruction word coeffs equ $0 # Load a coefficient Designed for DSP applications input equ $ffe0 # Memory-mapped I/O clr a x:(r0)+, x0 y:(r4)+, y0 output equ $ffe1 Orthogonal instruction set rep #n-1 # Repeat next instruction n-1 times org p:start # Locate in prog. memory # a = x0 × y0 Big, uniform register file (16 32-bit registers) move #samples, r0 # Pointers to samples # Next sample move #coeffs, r4 # and coefficients # Next coefficient Better compiler target than 56001 move #n-1, m0 # Prepare circular buffer mac x0,y0,a x:(r0)+, x0 y:(r4)+, y0 Deeply pipelined (up to 15 levels) move m0, m4 macr x0,y0,a (r0)- Complicated, but more regular, datapath movep a, y:output # Write output sample Pipelining on the C6 FIR in One 'C6 Assembly Instruction Peripherals One instruction issued per clock cycle Load a halfword (16 bits) Often the whole point of the system Very deep pipeline Do this on unit D1 Memory-mapped I/O FIRLOOP: • 4 fetch cycles LDH .D1 *A1++, A2 ; Fetch next sample • Magical memory locations that make something || LDH .D2 *B1++, B2 ; Fetch next coeff.
Load more

Recommended publications
  • Also Includes Slides and Contents From
    The Compilation Toolchain Cross-Compilation for Embedded Systems Prof. Andrea Marongiu ([email protected]) Toolchain The toolchain is a set of development tools used in association with source code or binaries generated from the source code • Enables development in a programming language (e.g., C/C++) • It is used for a lot of operations such as a) Compilation b) Preparing Libraries Most common toolchain is the c) Reading a binary file (or part of it) GNU toolchain which is part of d) Debugging the GNU project • Normally it contains a) Compiler : Generate object files from source code files b) Linker: Link object files together to build a binary file c) Library Archiver: To group a set of object files into a library file d) Debugger: To debug the binary file while running e) And other tools The GNU Toolchain GNU (GNU’s Not Unix) The GNU toolchain has played a vital role in the development of the Linux kernel, BSD, and software for embedded systems. The GNU project produced a set of programming tools. Parts of the toolchain we will use are: -gcc: (GNU Compiler Collection): suite of compilers for many programming languages -binutils: Suite of tools including linker (ld), assembler (gas) -gdb: Code debugging tool -libc: Subset of standard C library (assuming a C compiler). -bash: free Unix shell (Bourne-again shell). Default shell on GNU/Linux systems and Mac OSX. Also ported to Microsoft Windows. -make: automation tool for compilation and build Program development tools The process of converting source code to an executable binary image requires several steps, each with its own tool.
    [Show full text]
  • Computer Architecture and Assembly Language
    Computer Architecture and Assembly Language Gabriel Laskar EPITA 2015 License I Copyright c 2004-2005, ACU, Benoit Perrot I Copyright c 2004-2008, Alexandre Becoulet I Copyright c 2009-2013, Nicolas Pouillon I Copyright c 2014, Joël Porquet I Copyright c 2015, Gabriel Laskar Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being just ‘‘Copying this document’’, no Front-Cover Texts, and no Back-Cover Texts. Introduction Part I Introduction Gabriel Laskar (EPITA) CAAL 2015 3 / 378 Introduction Problem definition 1: Introduction Problem definition Outline Gabriel Laskar (EPITA) CAAL 2015 4 / 378 Introduction Problem definition What are we trying to learn? Computer Architecture What is in the hardware? I A bit of history of computers, current machines I Concepts and conventions: processing, memory, communication, optimization How does a machine run code? I Program execution model I Memory mapping, OS support Gabriel Laskar (EPITA) CAAL 2015 5 / 378 Introduction Problem definition What are we trying to learn? Assembly Language How to “talk” with the machine directly? I Mechanisms involved I Assembly language structure and usage I Low-level assembly language features I C inline assembly Gabriel Laskar (EPITA) CAAL 2015 6 / 378 I Programmers I Wise managers Introduction Problem definition Who do I talk to? I System gurus I Low-level enthusiasts Gabriel Laskar (EPITA) CAAL
    [Show full text]
  • Compiler Construction
    Compiler Construction Chapter 11 Compiler Construction Compiler Construction 1 A New Compiler • Perhaps a new source language • Perhaps a new target for an existing compiler • Perhaps both Compiler Construction Compiler Construction 2 Source Language • Larger, more complex languages generally require larger, more complex compilers • Is the source language expected to evolve? – E.g., Java 1.0 ! Java 1.1 ! . – A brand new language may undergo considerable change early on – A small working prototype may be in order – Compiler writers must anticipate some amount of change and their design must therefore be flexible – Lexer and parser generators (like Lex and Yacc) are therefore better than hand- coding the lexer and parser when change is inevitable Compiler Construction Compiler Construction 3 Target Language • The nature of the target language and run-time environment influence compiler construction considerably • A new processor and/or its assembler may be buggy Buggy targets make it difficult to debug compilers for that target! • A successful source language will persist over several target generations – E.g., 386 ! 486 ! Pentium ! . – Thus the design of the IR is important – Modularization of machine-specific details is also important Compiler Construction Compiler Construction 4 Compiler Performance Issues • Compiler speed • Generated code quality • Error diagnostics • Portability • Maintainability Compiler Construction Compiler Construction 5 Compiler Speed • Reduce the number of modules • Reduce the number of passes Perhaps generate machine
    [Show full text]
  • DSP56303 Product Brief, Rev
    Freescale Semiconductor DSP56303PB Product Brief Rev. 2, 2/2005 DSP56303 24-Bit Digital Signal Processor 16 6 6 3 Memory Expansion Area The DSP56303 is intended Triple X Data HI08 ESSI SCI PrograM Y Data for use in telecommunication Timer RAM RAM RAM 4096 × 24 2048 × 24 2048 × 24 applications, such as multi- bits bits bits line voice/data/ fax (default) (default) (default) processing, video Peripheral Expansion Area conferencing, audio PM_EB XM_EB PIO_EB YAB YM_EB applications, control, and Address External 18 Generation XAB Address general digital signal Unit PAB Bus Address Six-Channel DAB Switch processing. DMA Unit External 24-Bit Bus 13 Bootstrap DSP56300 Interface ROM and Inst. Core Cache Control Control DDB 24 Internal YDB External Data XDB Data Bus Bus PDB Switch Data Switch GDB EXTAL Power Clock Management Data ALU 5 Generator Program Program Program × + → XTAL Interrupt Decode Address 24 24 56 56-bit MAC JTAG PLL Two 56-bit Accumulators Controller Controller Generator 56-bit Barrel Shifter OnCE™ DE 2 MODA/IRQA MODB/IRQB RESET MODC/IRQC PINIT/NMI MODD/IRQD Figure 1. DSP56303 Block Diagram The DSP56303 is a member of the DSP56300 core family of programmable CMOS DSPs. Significant architectural features of the DSP56300 core family include a barrel shifter, 24-bit addressing, instruction cache, and DMA. The DSP56303 offers 100 million multiply-accumulates per second (MMACS) using an internal 100 MHz clock at 3.0–3.6 volts. The DSP56300 core family offers a rich instruction set and low power dissipation, as well as increasing levels of speed and power to enable wireless, telecommunications, and multimedia products.
    [Show full text]
  • Low Power Asynchronous Digital Signal Processing
    LOW POWER ASYNCHRONOUS DIGITAL SIGNAL PROCESSING A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Science & Engineering October 2000 Michael John George Lewis Department of Computer Science 1 Contents Chapter 1: Introduction ....................................................................................14 Digital Signal Processing ...............................................................................15 Evolution of digital signal processors ....................................................17 Architectural features of modern DSPs .........................................................19 High performance multiplier circuits .....................................................20 Memory architecture ..............................................................................21 Data address generation .........................................................................21 Loop management ..................................................................................23 Numerical precision, overflows and rounding .......................................24 Architecture of the GSM Mobile Phone System ...........................................25 Channel equalization ..............................................................................28 Error correction and Viterbi decoding ...................................................29 Speech transcoding ................................................................................31 Half-rate and enhanced
    [Show full text]
  • Rlsc & DSP Advanced Microprocessor System Design
    Purdue University Purdue e-Pubs ECE Technical Reports Electrical and Computer Engineering 3-1-1992 RlSC & DSP Advanced Microprocessor System Design; Sample Projects, Fall 1991 John E. Fredine Purdue University, School of Electrical Engineering Dennis L. Goeckel Purdue University, School of Electrical Engineering David G. Meyer Purdue University, School of Electrical Engineering Stuart E. Sailer Purdue University, School of Electrical Engineering Glenn E. Schmottlach Purdue University, School of Electrical Engineering Follow this and additional works at: http://docs.lib.purdue.edu/ecetr Fredine, John E.; Goeckel, Dennis L.; Meyer, David G.; Sailer, Stuart E.; and Schmottlach, Glenn E., "RlSC & DSP Advanced Microprocessor System Design; Sample Projects, Fall 1991" (1992). ECE Technical Reports. Paper 302. http://docs.lib.purdue.edu/ecetr/302 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. RISC & DSP Advanced Microprocessor System Design Sample Projects, Fall 1991 John E. Fredine Dennis L. Goeckel David G. Meyer Stuart E. Sailer Glenn E. Schmottlach TR-EE 92- 11 March 1992 School of Electrical Engineering Purdue University West Lafayette, Indiana 47907 RlSC & DSP Advanced Microprocessor System Design Sample Projects, Fall 1991 John E. Fredine Dennis L. Goeckel David G. Meyer Stuart E. Sailer Glenn E. Schrnottlach School of Electrical Engineering Purdue University West Lafayette, Indiana 47907 Table of Contents Abstract ...................................................................................................................
    [Show full text]
  • Introduction to Digital Signal Processors
    INTRODUCTION TO Accumulator architecture DIGITAL SIGNAL PROCESSORS Memory-register architecture Prof. Brian L. Evans in collaboration with Niranjan Damera-Venkata and Magesh Valliappan Load-store architecture Embedded Signal Processing Laboratory The University of Texas at Austin Austin, TX 78712-1084 http://anchovy.ece.utexas.edu/ Outline n Signal processing applications n Conventional DSP architecture n Pipelining in DSP processors n RISC vs. DSP processor architectures n TI TMS320C6x VLIW DSP architecture n Signal and image processing applications n Signal processing on general-purpose processors n Conclusion 2 Signal Processing Applications n Low-cost embedded systems 4 Modems, cellular telephones, disk drives, printers n High-throughput applications 4 Halftoning, radar, high-resolution sonar, tomography n PC based multimedia 4 Compression/decompression of audio, graphics, video n Embedded processor requirements 4 Inexpensive with small area and volume 4 Deterministic interrupt service routine latency 4 Low power: ~50 mW (TMS320C5402/20: 0.32 mA/MIP) 3 Conventional DSP Architecture n High data throughput 4 Harvard architecture n Separate data memory/bus and program memory/bus n Three reads and one or two writes per instruction cycle 4 Short deterministic interrupt service routine latency 4 Multiply-accumulate (MAC) in a single instruction cycle 4 Special addressing modes supported in hardware n Modulo addressing for circular buffers (e.g. FIR filters) n Bit-reversed addressing (e.g. fast Fourier transforms) 4Instructions to keep the
    [Show full text]
  • Embedded Firmware Development Languages/Options
    Module -4 Embedded System Design Concepts Characteristics & Quality Attributes of Embedded Systems Characteristics of Embedded System Each Embedded System possess a set of characteristics which are unique to it. Some important characteristics of embedded systems are: Application & Domain Specific Reactive & Real Time Operates in ‘harsh’ environment Distributed Small size and Weight Power Concerns Quality Attributes of Embedded Systems: Represent the non-functional requirements that needs to be addressed in the design of an embedded system. The various quality attributes that needs to be addressed in any embedded system development are broadly classified into Operational Quality Attributes Refers to the relevant quality attributes related to tan embedded system when it is in the operational mode or ‘online ’ mode Non-Operational Quality Attributes The Quality attributes that needs to be addressed for the product ‘not’ on the basis of operational aspects are grouped under this category Operational Quality Attributes Response Throughput Reliability Maintainability Security Safety Non-Operational Quality Attributes Testability & Debug-ability Evolvability Portability Time to Prototype and Market Per Unit and Total Cost Washing Machine – Application Specific Embedded System V Extensively used in Home Automation for washing and drying clothes V Contains User Interface units (I/O) like Keypads, Display unit, LEDs for accepting user inputs and providing visual indications V Contains sensors like, water level sensor, temperature
    [Show full text]
  • Assembly Language Programming by James and Jarrod Parkes Abstract
    Technical Course Curriculum and Annotated Bibliography CS308: Assembly Language Programming By James and Jarrod Parkes Abstract At the University of Alabama in Huntsville, the Computer Science (CS) Department is facing a decreased student interest in their CS 308 assembly language course. As a result, this new course curriculum and annotated bibliography have been created to restore excitement into the program. Since today's students are seeking innovative applications for programming, this curriculum teaches the 6502 assembly language with a focus on the Nintendo Entertainment System (NES)--a vintage video game console. While linearly covering the required assembly language material, this curriculum incorporates interactive examples from classic NES titles such as Super Mario and The Legend of Zelda. With this curriculum, CS professors are also given the tools to guiding students through the development of their very own NES video games. By the end of the curriculum, professors will be fully equipped to teach the 6502 assembly language while providing students the rewarding experience of game development. Additionally, the annotated bibliography includes supplementary texts and online articles to help reinforce topics for professors and students. Source: Google Images ii Table of Contents Introduction to the Assembly Language Course....................................................... 1! What is an Assembly Language? .................................................................................. 1! How is this Course Structured?...................................................................................
    [Show full text]
  • Chapter 1 Basic Principles of Programming Languages
    Chapter 1 Basic Principles of Programming Languages Although there exist many programming languages, the differences among them are insignificant compared to the differences among natural languages. In this chapter, we discuss the common aspects shared among different programming languages. These aspects include: programming paradigms that define how computation is expressed; the main features of programming languages and their impact on the performance of programs written in the languages; a brief review of the history and development of programming languages; the lexical, syntactic, and semantic structures of programming languages, data and data types, program processing and preprocessing, and the life cycles of program development. At the end of the chapter, you should have learned: what programming paradigms are; an overview of different programming languages and the background knowledge of these languages; the structures of programming languages and how programming languages are defined at the syntactic level; data types, strong versus weak checking; the relationship between language features and their performances; the processing and preprocessing of programming languages, compilation versus interpretation, and different execution models of macros, procedures, and inline procedures; the steps used for program development: requirement, specification, design, implementation, testing, and the correctness proof of programs. The chapter is organized as follows. Section 1.1 introduces the programming paradigms, performance, features, and the development of programming languages. Section 1.2 outlines the structures and design issues of programming languages. Section 1.3 discusses the typing systems, including types of variables, type equivalence, type conversion, and type checking during the compilation. Section 1.4 presents the preprocessing and processing of programming languages, including macro processing, interpretation, and compilation.
    [Show full text]
  • Fifty Years in Home Computing, the Digital Computer and Its Private Use(Er)S
    International Journal of Parallel, Emergent and Distributed Systems ISSN: 1744-5760 (Print) 1744-5779 (Online) Journal homepage: https://www.tandfonline.com/loi/gpaa20 Fifty years in home computing, the digital computer and its private use(er)s Stefan Höltgen To cite this article: Stefan Höltgen (2020) Fifty years in home computing, the digital computer and its private use(er)s, International Journal of Parallel, Emergent and Distributed Systems, 35:2, 170-184, DOI: 10.1080/17445760.2019.1597085 To link to this article: https://doi.org/10.1080/17445760.2019.1597085 © 2019 The Author(s). Published by Informa UK Limited, trading as Taylor & Francis Group Published online: 26 Mar 2019. Submit your article to this journal Article views: 354 View related articles View Crossmark data Full Terms & Conditions of access and use can be found at https://www.tandfonline.com/action/journalInformation?journalCode=gpaa20 INTERNATIONAL JOURNAL OF PARALLEL, EMERGENT AND DISTRIBUTED SYSTEMS 2020, VOL. 35, NO. 2, 170–184 https://doi.org/10.1080/17445760.2019.1597085 Fifty years in home computing, the digital computer and its private use(er)s Stefan Höltgen Department for Musicology and Media Science, Humboldt University, Berlin, Germany ABSTRACT ARTICLE HISTORY The following chapter will discuss the relation between home computer his- Received 13 March 2019 tory and computer programming – with a focus on game programming. Accepted 16 March 2019 The nurseries of the early 1980s are the origins of the later computer game KEYWORDS industry and the private use of microcomputers becomes an essential part Homecomputer; computer of the ‘playful’ exploration and emancipation of technology.
    [Show full text]
  • Ada: the Maginot Line of Languages -Or
    BACKTALK Ada: The Maginot Line of Languages -or- One language to rule them all, One language to find them, One language to (withbring apologiesthem all toan J.R.R.Tolkien)d in the darkness bind them. uring World War I, more than one million French citizens The Ada programming language shall become the single were killed, and another estimated four to five million common programming language for Defense mission-criti- were wounded. Many French politicians and generals thought that cal applications. Effective 1 January 1984 for programs the Treaty of Versailles (which ended the war, and was supposed to entering Advanced Development and 1 July 1984 for pro- punish the defeated countries and prevent further conflict) was grams entering Full-Scale Engineering Development, Ada Dinsufficient protection. France was justifiably concerned that the shall be the programming language. treaty was really just an armistice and that war would ultimately resume (as it did – World War II). To protect France, many influ- The problem was that back in 1983 there weren’t many compil- ential politicians and generals were in favor of an aggressive set of ers, tools, or experienced programmers. Compilers were slow and fortifications. There were many studies and meetings, and based on tended to consume all the resources of even high-end computers. the consensus of opinion, the Maginot Line was built. The general feeling among us Ada zealots was that the DeLauer The Maginot Line, named after French minister of defense memo was premature and actually worked against the cause of Ada. André Maginot, was a line of concrete fortifications, tank obstacles, Because of the lack of tools, compilers, and trained programmers, machine gun posts, and other defenses which were built along the many developers either received a waiver from the Ada mandate or Italian and German border.
    [Show full text]