DOCSLIB.ORG

On Hardware and Hardware Models for Embedded Real-Time Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On Hardware and Hardware Models for Embedded Real-Time Systems On Hardware and Hardware Models for Embedded Real-Time Systems Jakob Engblom∗ Dept. of Information Technology, Uppsala University P.O. Box 325, SE-751 05 Uppsala, Sweden [email protected] / http://www.docs.uu.se/~jakob effects if deadlines are missed or some other timing- Abstract related bugs manifest themselves. When developing embedded real-time systems, de- When building an embedded real-time systems, the signers and programmers rely on various forms of choice of hardware platform is very important to create scheduling and timing analysis. At some point, all an analyzable and predictable system. Also, the quality such analyses must account for the hardware used to of the models of the hardware used in software tools obtain execution time information, and if the analysis is very important to the correctness of timing analysis method does not accurately reflect the hardware char- and the integrity of the system. acteristics, the result is likely to be a bad analysis and In this paper, we discuss some of the aspects of how potentially a bad system. to build hardware models that are correct visavi the The choice of hardware, specifically the microproces- hardware, and how to select hardware that allows real- sor or microcontroller to use, has a profound influence time systems to be constructed in a reliable fashion. on the analyzability of a system. The timing behav- The purpose of this paper is to inspire some discus- ior of a complex CPU core is very hard to understand sion regarding how real-time systems are designed and (even without a cached memory system). Thus, sys- built and verified, from software, hardware, and tools tems have to be designed to facilitate analysis, from standpoints. the hardware and up. Keywords: Embedded Systems, Real-Time Systems, 2. On the Quality of Hardware Models Computer Architecture, Hardware Selection, Hardware Analysis, Hardware Modelling In embedded systems development, hardware mod- els (software running on the cross-development system) 1. Introduction are used for most of the development work and analysis Thanks to the ever-advancing performance of em- of a system. The quality of such models form a key part bedded computer technology, an increasing number of of the correctness argument for a system. The use of systems are being built and designed where micropro- a bad hardware model (even for eminently predictable cessors and microcontrollers perform substantial con- and analyzable hardware) will put the system integrity trolling tasks. Vehicles, appliances, industrial plants, at risk. toys, mobile phones: embedded systems are every- Looking at the design flow for hardware models, sev- where around us. Most of these embedded systems eral sources of errors can be identified. Figure 1 shows a have real-time constraints, and potentially dangerous schematic flow of the design and implementation work separating a CPU simulator (the most important type ∗ This work is performed within the Advanced Software of hardware model) from the physical chips shipped by Technology (ASTEC, http://www.docs.uu.se/astec)compe- tence center, supported by the Swedish National Innovation the manufacturer. Systems’ Administration (VINNOVA, http://www.vinnova.se). The manual writing is probably the biggest source of Jakob is an industrial PhD student at IAR Systems errors. The manual writers have to interpret the chip (http://www.iar.com) and Uppsala university, sharing his time design, and this interpretation can be different from between research and development work. Presented at the IEEE Real-Time Embedded System Work- that of the hardware implementers. Simple typos can shop, Dec. 3, 2001. introduce more errors. sible to shortcut the process by using the VHDL code Chip design in some manner. Unfortunately, VHDL simulators are orders of magnitude slower than a regular cycle-correct Hardware Manual simulators, and automatic abstraction from VHDL to implementation Writing a cycle-level simulator is not feasible. VHDL Model Users Simulator 2.1. Experience Report 1 manual Design Compilation & Black and Shen [4] report their experience in validat- Fabrication Simulator ing a model of a PowerPC 604 processor. The method Implementation employed was to execute many test cases (small pro- grams) on both their simulator and a real CPU. The Chip Correspondence? Simulator performance counters of the PowerPC were used to check the correctness of the model. For such a com- Figure 1. Workflow of Hardware Modeling plex chip, this is a reasonable approach. As a sanity Often, many of the details needed to implement a check, they also executed a number of larger programs simulator (or an optimizing compiler) are abstracted and compared the cycle counts on the simulator and away or glossed over. Many manuals do not describe the hardware. the detailed function of a CPU pipeline, but instead The results are interesting, since they never man- give simple approximate cycle counts for instructions age to get a perfect correspondence. Fixing an error (which is a grave oversimplification for a pipelined pro- in the model sometimes revealed other errors that had cessor) [1, 3, 10]. Thus, the manuals typically have a been masked by the first, and the total error could thus rather tenuous relation to the chips they are supposed increase for some fixes. However, over time, the accu- to document, which is a major problem for hardware racy of the model increased, both for the performance modeling. counter agreements and the cycle counts for the tested Even though hardware engineering is in much bet- larger programs. For their final model, about 20 per- ter shape than software engineering, bugs can be in- cent of the individual small tests failed to be within one troduced in the hardware implementation. A famous clock cycle of the hardware timing, while the large test example is the Pentium FDIV bug [20]. The presence programs showed an error between 2 and 10 percent. of extensive errata lists for hardware further indicate The errors were both positive and negative, indicat- that hardware does contain bugs which are not found ing overestimates and underestimates of the execution until after products are shipping. It should be noted time. that bugs regarding the timing behavior of chips are Their conclusion is that systematic validation quite common while functional bugs are comparatively against hardware is necessary to build a performance rare, since instruction timing is usually not validated model that users can have confidence in using, and that as extensively as functional correctness [12, 17]. achieving a reliable and precise model requires a large The hardware compilation and fabrication do not development effort. The complexity of current high- usually generate user-visible bugs. end microprocessors makes the development of reliable The simulator implementation also has some bug hardware models a “great challenge”. sources. In the simulator design step, it is possible to introduce errors by misinterpreting the manuals and 2.2. Experience Report 2 ignoring important features in the model. During sim- Gibson et al. investigated the quality of the models ulator implementation, errors are introduced as the de- used in the research and development of the Stanford signed simulation model is converted into actual pro- FLASH multiprocessor [8]. The FLASH project em- gram code. ployed several different simulators during the develop- In summary, the “timing correct” hardware models ment of the system, and collected a large amount of we use in real-time development and research are sev- data on how well the simulators and the hardware cor- eral bug-inducing steps away from the actual hardware, related. Their testing was initially based on running which makes the use of such models quite questionable. large multi-processor numerical applications and com- It is necessary to find a way to validate the hardware paring the resulting execution times. Smaller bench- models used when building real-time systems. To in- marks were introduced to help pinpoint specific per- vestigate this, we look at some work performed in val- formance mismatches later in the process. idating CPU simulators. The CPU models used were all based on generic sim- Looking at Figure 1, it seems that it would be pos- ulation packages like Mipsy and MXS, which were given parameters to closely emulate the MIPS R10000 CPUs Manual Writing used. However, these models were not able to capture The multiply instruction sometimes writes two registers, which causes a delay of one cycle (probably the register bank all relevant details of the CPU, giving execution time has only one write port). This was not documented. results very different from the hardware for key parts Some forms of jump instructions were documented as being of their code like TLB miss handlers. This is claimed one cycle faster than they actually were. to be a general problem with generic CPU simulators: Simulator Design The V850E has a main pipeline and a secondary pipeline. It they are not sufficiently configurable to model all the was possible for instructions to continue issuing to the sec- quirky cases of the real hardware. ondary pipeline even if the main pipeline was busy, which is The conclusions for simulator construction is that not possible in the hardware. simulation technology is barely able to keep up with the One instruction had been forgotten in the simulator imple- mentation. increased complexity of modern computer systems, and Simulator Implementation that hardware to compare with is necessary in order to Signed and unsigned division has a one clock-cycle difference build a good model. in execution time, which was implemented the wrong way around. 2.3. Experience Report 3 Some bit-manipulation instructions did not keep certain re- sources locked for their entire execution, letting other in- Mont´an [16], working within our project, validated structions slip by, eventually leading to internally inconsistent a trace-driven simulator for the NEC V850E [19], used states and thus a crash of the simulator.
Load more

Recommended publications
  • Wdv-Notes Stand: 29.DEZ.1994 (2.) 329 Intel Pentium – Business Must Learn from the Debacle
    wdv-notes Stand: 29.DEZ.1994 (2.) 329 Intel Pentium – Business Must Learn from the Debacle. Wiss.Datenverarbeitung © 1994–1995 Edited by Karl-Heinz Dittberner FREIE UNIVERSITÄT BERLIN Theo Die kanadische Monatszeitschrift The Im folgenden sowie in den wdv-notes verbreitet werden, wenn dabei die folgen- Computer Post, Winnipeg veröffentlicht Nr. 330 werden diese Artikel im Original den Spielregeln beachtet werden. in mehreren Artikeln in ihrer Januar-Aus- nachgedruckt. Der Dank dafür geht an Permission is hereby granted to copy gabe 1995 eine exzellente erste Zusam- Sylvia Douglas von The Computer Post, this article electronically or in any other menfassung des Debakels um den Defekt 301 – 68 Higgins Avenue, Winnipeg, Ma- form, provided it is reproduced without des Pentium-Mikroprozessors [1–2] des nitoba, Canada, Email: SDouglas@post. alteration, and you credit it to The Compu- Computergiganten Intel. mb.ca. Diese Artikel dürfen auch weiter- ter Post. Intel’s top of the line Pentium™ microproc- This particular error in the Pentium was in essor chip has turned out to have a slight flaw the floating-point divide unit. Intel manage- Editorial: The Computer Post – Jan.95 in its character: when dividing certain rare ment was concerned enough about it that pairs of floating point numbers, it gives the they pulled together a special team to assess The Way it Will Be wrong answer. For anyone who owns a Pen- the implications. tium-based computer, or was thinking about This month you’ll find we’re reporting a In the words of Andrew Grove, Intel’s CEO, buying one, or is just feeling curious, here lot of background information on Intel’s posting later to the Internet [3], “We were are..
    [Show full text]
  • Coverstory by Robert Cravotta, Technical Editor
    coverstory By Robert Cravotta, Technical Editor u WELCOME to the 31st annual EDN Microprocessor/Microcontroller Di- rectory. The number of companies and devices the directory lists continues to grow and change. The size of this year’s table of devices has grown more than NEW PROCESSOR OFFERINGS 25% from last year’s. Also, despite the fact that a number of companies have disappeared from the list, the number of companies participating in this year’s CONTINUE TO INCLUDE directory has still grown by 10%. So what? Should this growth and change in the companies and devices the directory lists mean anything to you? TARGETED, INTEGRATED One thing to note is that this year’s directory has experienced more compa- ny and product-line changes than the previous few years. One significant type PERIPHERAL SETS THAT SPAN of change is that more companies are publicly offering software-programma- ble processors. To clarify this fact, not every company that sells processor prod- ALL ARCHITECTURE SIZES. ucts decides to participate in the directory. One reason for not participating is that the companies are selling their processors only to specific customers and are not yet publicly offering those products. Some of the new companies par- ticipating in this year’s directory have recently begun making their processors available to the engineering public. Another type of change occurs when a company acquires another company or another company’s product line. Some of the acquired product lines are no longer available in their current form, such as the MediaQ processors that Nvidia acquired or the Triscend products that Arm acquired.
    [Show full text]
  • Detecting and Removing Malicious Hardware Automatically
    Appears in Proceedings of the 31st IEEE Symposium on Security & Privacy (Oakland), May 2010 Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically Matthew Hicks, Murph Finnicum, Samuel T. King Milo M. K. Martin, Jonathan M. Smith University of Illinois at Urbana-Champaign University of Pennsylvania Abstract hardware-level vulnerabilities would likely require phys- ically replacing the compromised hardware components. The computer systems security arms race between at- A hardware recall similar to Intel’s Pentium FDIV bug tackers and defenders has largely taken place in the do- (which cost 500 million dollars to recall five million main of software systems, but as hardware complexity chips) has been estimated to cost many billions of dollars and design processes have evolved, novel and potent today [7]. Furthermore, the skill required to replace hard- hardware-based security threats are now possible. This ware and the rise of deeply embedded systems ensure paper presents a hybrid hardware/software approach to that vulnerable systems will remain in active use after the defending against malicious hardware. discovery of the vulnerability. Second, hardware is the We propose BlueChip, a defensive strategy that has lowest layer in the computer system, providing malicious both a design-time component and a runtime component. hardware with control over the software running above. During the design verification phase, BlueChip invokes This low-level control enables sophisticated and stealthy a new technique, unused circuit identification (UCI), attacks aimed at evading software-based defenses. to identify suspicious circuitry—those circuits not used Such an attack might use a special, or unlikely, event to or otherwise activated by any of the design verification trigger deeply buried malicious logic which was inserted tests.
    [Show full text]
  • Errata Sheet NG For
    16/32-Bit Architecture XC27x5X Derivatives 16/32-Bit Single-Chip Microcontroller with 32-Bit Performance XC2000 Family / Base Line Errata Sheet V1.5 2013-02 Microcontrollers Edition 2013-02 Published by Infineon Technologies AG 81726 Munich, Germany © 2013 Infineon Technologies AG All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics. With respect to any examples or hints given herein, any typical values stated herein and/or any information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation, warranties of non-infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices, please contact the nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements, components may contain dangerous substances. For information on the types in question, please contact the nearest Infineon Technologies Office. Infineon Technologies components may be used in life-support devices or systems only with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered.
    [Show full text]
  • Can the Computer Be Wrong?
    Can the computer be wrong? Wojciech Myszka Department of Mechanics, Materials and Biomedical Engineering January 2021 1 Data 2 Human (operator) 3 Hardware (inevitable) 4 Hardware 5 Manufacturer fault 6 Software 7 Bug free software 8 List of software bugs Data Absolute error I I was talking about this in one of the previous lectures. I One of the main sources of errors are data. I Knowing the range of each value allows us to predict values of the result. I This can be difficult and tricky. I However, in most cases we assume that the data values are correct and believe in computer calculations. Human (operator) Operator I In general, it is difficult to take into account human errors. I These include: I not understanding the problem solved by the program, I errors in preparing input data, I wrong answer to the computer prompt, I ... Hardware (inevitable) Number of bits This is a quite different source of error. 1. Most of todays computers have I 32 or 64 bits processors 2. What does this mean? Number of bits — rangeI 1. The biggest integer value I 32 bits: from −231 to 231 − 1 (−2; 147; 483; 648 to 2; 147; 483; 647) or two billion, one hundred forty-seven million, four hundred eighty-three thousand, six hundred forty-seven I 64 bits: from −263 to 263 − 1 (−9; 223; 372; 036; 854; 775; 808 to 9; 223; 372; 036; 854; 775; 807) nine quintillion two hundred twenty three quadrillion three hundred seventy two trillion thirty six billion eight hundred fifty four million seven hundred seventy five thousand eight hundred and seven 2.
    [Show full text]
  • The Insider's Guide to Planning 166 Family Designs
    Issue B Frequency (MHz) Frequency Rx2 (Ohm) Rx2 CX1 (pF) CX1 CX2 (pF) CX2 CL (pF) CL C0typ (pF) C0typ R1typ (Ohm) R1typ R1max (Ohm) R1max R1max (TK) (Ohm) R1max Pw (uW) Pw Rqmax (Ohm) Rqmax Safety Factor (SF) Factor Safety 40 0 12 15 13 7 10 50 60 420 300 2.11 32 0 12 15 11 5 15 50 60 520 390 3.07 24 180 15 22 12 5 15 50 60 510 390 3.24 20 390 8.2 39 10 4 20 60 80 375 560 3.57 18 390 12 39 14 4 20 60 80 335 540 4.08 16 390 12 47 13 4 20 60 80 353 580 4.24 12 390 15 47 13 4 30 70 90 312 1000 6.50 10 390 15 47 14 3 30 80 100 216 1200 8.14 8 390 15 47 15 3 35 80 100 372 1800 12.50 6 390 15 47 14 3 35 80 140 100 2200 10.66 5 390 22 47 18 3 35 80 140 110 2700 14.17 4 390 22 47 16 4 20 80 150 46 3300 14.08 166 Decoupling capacitor on reverse of board CB Vcc Vss XTAL1 XTAL2 RX CX1 CX2 = Connections to Crystal ground layer { time_for_60_degreesThe = CC15 - time_las Insiders Guide To CC0 = CC15 + (Injector_Firing _Angle time_last_60 = CC15 ; } CC15 Interrupt, cylinder 0 Injector Firing Angle 0 0 Injector 3 6 Opening Time Planning 166 5 7 1 CC0 Interrupt, 11 cylinder 0 injector { CC0 += Inje CC3 Interrupt, 10 8 cylinder 3 injector 4 2 Family Designs jector_Pulse_Width ; } Injector 0 Opening Time 9 3 Injector Firing Angle 3 CC15 Interrupt, cylinder 3 { time_for_60_degrees = CC15 - time_last_6 CC3 = CC15 + (Injector_Firing _Angle * t time_last_60 = CC15 ; } VAREF Analog Voltage Varef input Reference Internal capacitance Resistance Analog Voltage ~ Reference GND Optional Over-Voltage Protection Resistor AN0 Rap Signal Source Internal A/D Convertor Resistance Sample & Hold Capacitor A/D Convertor Analog Signal ~ Voltage Source VAGND 167 GND 166 Designers Guide - Page 1 This guide contains basic information that is useful when doing your first 166 family design.
    [Show full text]
  • A Hybrid-Parallel Architecture for Applications in Bioinformatics
    A Hybrid-parallel Architecture for Applications in Bioinformatics M.Sc. Jan Christian Kässens Dissertation zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) der Technischen Fakultät der Christian-Albrechts-Universität zu Kiel eingereicht im Jahr 2017 Kiel Computer Science Series (KCSS) 2017/4 dated 2017-11-08 URN:NBN urn:nbn:de:gbv:8:1-zs-00000335-a3 ISSN 2193-6781 (print version) ISSN 2194-6639 (electronic version) Electronic version, updates, errata available via https://www.informatik.uni-kiel.de/kcss The author can be contacted via [email protected] Published by the Department of Computer Science, Kiel University Computer Engineering Group Please cite as: Ź Jan Christian Kässens. A Hybrid-parallel Architecture for Applications in Bioinformatics Num- ber 2017/4 in Kiel Computer Science Series. Department of Computer Science, 2017. Dissertation, Faculty of Engineering, Kiel University. @book{Kaessens17, author = {Jan Christian K\"assens}, title = {A Hybrid-parallel Architecture for Applications in Bioinformatics}, publisher = {Department of Computer Science, CAU Kiel}, year = {2017}, number = {2017/4}, doi = {10.21941/kcss/2017/4}, series = {Kiel Computer Science Series}, note = {Dissertation, Faculty of Engineering, Kiel University.} } © 2017 by Jan Christian Kässens ii About this Series The Kiel Computer Science Series (KCSS) covers dissertations, habilitation theses, lecture notes, textbooks, surveys, collections, handbooks, etc. written at the Department of Computer Science at Kiel University. It was initiated in 2011 to support authors in the dissemination of their work in electronic and printed form, without restricting their rights to their work. The series provides a unified appearance and aims at high-quality typography. The KCSS is an open access series; all series titles are electronically available free of charge at the department’s website.
    [Show full text]
  • Datasheet CAN Driver Source Code
    Source Code CAN Driver Source Code - CANpie FD CAN driver for embedded applications The driver CANpie FD (Controller Area Network Program- ming Interface Environment) provides a standarized API for software engineering of CAN-based applications. The driver forms the basis for higher-layer protocols (CANopen / DeviceNet / J1939) and is available for a wide range of microcontroller platforms. Scalability and modu- lar design of the CANpie drivers facilitate implementation into individual target systems. Features • Modular design, scalable, easy to implement • Optimized for low resources (ROM / RAM) User Functions • Wide range of supported CAN controllers • Support of standard and extended frames (11-bit / 29-bit identifier) Core Functions Receive Transmit • Data flow by polling or interrupt driven FIFO FIFO • Supports virtual mailboxes Mailbox Access Filter Receive Transmit IRQ CAN hardware MicroControl GmbH & Co. KG · Junkersring 23 · 53844 Troisdorf · Germany · Fon +49 (0) 2241 256 59 - 0 · Fax +49 (0) 2241 256 59 - 11 · [email protected] I/O Module Steuerungen Protokollstacks Dienstleistungen www.microcontrol.net Technical Data CAN driver source code - CANpie FD Identifier • Standard Frame (11-bit) • Extended Frame (29-bit) Formats • Data Frame • Remote Frame • Error Frame (Receive) Monitoring of fault conditions • ACK (depending on controller) • Bit Error • Format Error • CRC Error • Stuff Error Dataflow • Interrupt • Polling Special Features • Mailbox access • Software Filter Order Number Description / CAN Controller 50.10.079
    [Show full text]
  • TASKING VX-Toolset for C166 User Guide TASKING VX-Toolset for C166 User Guide
    TASKING VX-toolset for C166 User Guide TASKING VX-toolset for C166 User Guide Copyright © 2006 Altium Limited. All rights reserved.You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, TASKING, and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. Table of Contents 1. C Language .................................................................................................................. 1 1.1. Data Types ......................................................................................................... 1 1.2. Changing the Alignment: __unaligned and __packed__ ............................................... 3 1.3. Accessing Memory .............................................................................................
    [Show full text]
  • P5 (Microarchitecture)
    P5 (microarchitecture) The Intel P5 Pentium family Produced From 1993 to 1999 Common manufacturer(s) • Intel Max. CPU clock rate 60 MHz to 300 MHz FSB speeds 50 MHz to 66 MHz Min. feature size 0.8pm to 0.25pm Instruction set x86 Socket(s) • Socket 4, Socket 5, Socket 7 Core name(s) P5. P54C, P54CS, P55C, Tillamook The original Pentium microprocessor was introduced on March 22, 1993.^^ Its microarchitecture, deemed P5, was Intel's fifth-generation and first superscalar x86 microarchitecture. As a direct extension of the 80486 architecture, it included dual integer pipelines, a faster FPU, wider data bus, separate code and data caches and features for further reduced address calculation latency. In 1996, the Pentium with MMX Technology (often simply referred to as Pentium MMX) was introduced with the same basic microarchitecture complemented with an MMX instruction set, larger caches, and some other enhancements. The P5 Pentium competitors included the Motorola 68060 and the PowerPC 601 as well as the SPARC, MIPS, and Alpha microprocessor families, most of which also used a superscalar in-order dual instruction pipeline configuration at some time. Intel's Larrabee multicore architecture project uses a processor core derived from a P5 core (P54C), augmented by multithreading, 64-bit instructions, and a 16-wide vector processing unit. T31 Intel's low-powered Bonnell [4i microarchitecture employed in Atom processor cores also uses an in-order dual pipeline similar to P5. Development The P5 microarchitecture was designed by the same Santa Clara team which designed the 386 and 486.^ Design work started in 1989;^ the team decided to use a superscalar architecture, with on-chip cache, floating-point, and branch prediction.
    [Show full text]
  • TASKING VX-Toolset for C166 User Guide
    TASKING VX-toolset for C166 User Guide MA119-800 (v3.1) October 25, 2012 Copyright © 2012 Altium Limited. All rights reserved.You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, TASKING, and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. Table of Contents 1. C Language .................................................................................................................. 1 1.1. Data Types ......................................................................................................... 1 1.2. Changing the Alignment: __unaligned and __packed__ ............................................... 3 1.3. Accessing Memory .............................................................................................
    [Show full text]
  • APA Newsletters NEWSLETTER on PHILOSOPHY and COMPUTERS
    APA Newsletters NEWSLETTER ON PHILOSOPHY AND COMPUTERS Volume 11, Number 1 Fall 2011 FROM THE EDITOR, PETER BOLTUC FROM THE CHAIR, DAN KOLAK SPECIAL SESSION DAVID L. ANDERSON “Special Session on ‘Machine Consciousness’” FEATURED ARTICLE JAAKKO HINTIKKA “Logic as a Theory of Computability” ARTICLES DARREN ABRAMSON AND LEE PIKE “When Formal Systems Kill: Computer Ethics and Formal Methods” HECTOR ZENIL “An Algorithmic Approach to Information and Meaning: A Formal Framework for a Philosophical Discussion” PENTTI O A HAIKONEN “Too Much Unity: A Reply to Shanahan” PHILOSOPHY AND ONLINE EDUCATION RON BARNETTE “Reflecting Back Twenty Years” © 2011 by The American Philosophical Association ISSN 2155-9708 FRANK MCCLUSKEY “Reflections from Teaching Philosophy Online” TERRY WELDIN-FRISCH “A Comparison of Four Distance Education Models” KRISTEN ZBIKOWSKI “An Invitation for Reflection: Teaching Philosophy Online” THOMAS URBAN “Distance Learning and Philosophy: The Term-Length Challenge” FEDERICO GOBBO “The Heritage of Gaetano Aurelio Lanzarone” APA NEWSLETTER ON Philosophy and Computers Piotr Bołtuć, Editor Fall 2011 Volume 11, Number 1 Terry Weldin-Frish, in his informative paper, compares the ROM THE DITOR experiences he had with online learning in philosophy first as a F E graduate student, reaching a Ph.D. entirely online, and later as a faculty member, at four different educational institutons in the UK and the US. Kristen Zbikowski presents a spirited defense Peter Boltuc of teaching philosophy online based on her experiences as an University of Illinois at Springfield online student and then a faculty member also teaching online courses. Thomas Urban raises a specific problem of the length I used to share the general enthusiasm about web-only of viable online philosophy courses.
    [Show full text]