ARM System Developer's Guide.pdf - Google Drive

ARM System Developer’s Guide Designing and Optimizing System Software

About the Authors Andrew N. Sloss Andrew Sloss received a B.Sc. in Computer Science from the University of Herefordshire (UK) in 1992 and was certified as a Chartered Engineer by the British Computer Society (C.Eng, MBCS). He has worked in the computer industry for over 16 years and has been involved with the ARM processor since 1987. He has gained extensive experience developing a wide range of applications running on the ARM processor. He designed the first editing systems for both Chinese and Egyptian Hieroglyphics executing on the ARM2 and ARM3 processors for Emerald Publishing (UK). Andrew Sloss has worked at ARM Inc. for over six years. He is currently a Technical Sales Engineer advising and supporting companies developing new products. He works within the U.S. Sales Organization and is based in Los Gatos, California. Dominic Symes Dominic Symes is currently a software engineer at ARM Ltd. in Cambridge, England, where he has worked on ARM-based embedded software since 1995. He received his B.A. and D.Phil. in Mathematics from Oxford University. He first programmed the ARM in 1989 and is particularly interested in algorithms and optimization techniques. Before joining ARM, he wrote commercial and public domain ARM software. Chris Wright Chris Wright began his embedded systems career in the early 80s at Lockheed Advanced Marine Systems. While at Advanced Marine Systems he wrote small software control systems for use on the Intel 8051 family of microcontrollers. He has spent much of his career working at the Lockheed Palo Alto Research Laboratory and in a software development group at Dow Jones Telerate. Most recently, Chris Wright spent several years in the Customer Support group at ARM Inc., training and supporting partner companies developing new ARM-based products. Chris Wright is currently the Director of Customer Support at Ultimodule Inc. in Sunnyvale, California. John Rayfield John Rayfield, an independent consultant, was formerly Vice President of Marketing, U.S., at ARM. In this role he was responsible for setting ARM’s strategic marketing direction in the U.S., and identifying opportunities for new technologies to serve key market segments. John joined ARM in 1996 and held various roles within the company, including Director of Technical Marketing and R&D, which were focused around new product/technology development. Before joining ARM, John held several engineering and management roles in the field of digital signal processing, software, hardware, ASIC and system design. John holds an M.Sc. in Signal Processing from the University of Surrey (UK) and a B.Sc.Hons. in Electronic Engineering from Brunel University (UK).

ARM System Developer’s Guide Designing and Optimizing System Software

Andrew N. Sloss Dominic Symes Chris Wright With a contribution by John Rayfield

AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Morgan Kaufmann is an imprint of Elsevier

Senior Editor Publishing Services Manager Project Manager Developmental Editor Editorial Assistant Cover Design Cover Image

Technical Illustration Composition Copyeditor Proofreader Indexer Interior printer Cover printer

Denise E.M. Penrose Simon Crump Sarah M. Hajduk Belinda Breyer Summer Block Dick Hannus Red Wing No.6 by Charles Biederman Collection Walker Art Center, Minneapolis Gift of the artist through the Ford Foundation Purchase Program, 1964 Dartmouth Publishing Cepha Imaging, Ltd. Ken Dellapenta Jan Cocker Ferreira Indexing The Maple-Vail Book Manufacturing Group Phoenix Color

Morgan Kaufmann Publishers is an imprint of Elsevier. 500 Sansome Street, Suite 400, San Francisco, CA 94111 This book is printed on acid-free paper. © 2004 by Elsevier Inc. All rights reserved. The programs, examples, and applications presented in this book and on the publisher’s Web site have been included for their instructional value. The publisher and the authors offer no warranty implied or express, including but not limited to implied warranties of fitness or merchantability for any particular purpose and do not accept any liability for any loss or damage arising from the use of any information in this book, or any error or omission in such information, or any incorrect use of these programs, procedures, and applications. Designations used by companies to distinguish their products are often claimed as trademarks or registered trademarks. In all instances in which Morgan Kaufmann Publishers is aware of a claim, the product names appear in initial capital or all capital letters. Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, mechanical, photocopying, scanning, or otherwise—without prior written permission of the publisher. Permissions may be sought directly from Elsevier’s Science & Technology Rights Department in Oxford, UK: phone: (+44) 1865 843830, fax: (+44) 1865 853333, e-mail: [email protected]. You may also complete your request on-line via the Elsevier homepage (http://elsevier.com) by selecting “Customer Support” and then “Obtaining Permissions.” Library of Congress Cataloging-in-Publication ; byte reverse the bit buffer prior to storing EOR tmp, bitbuffer, bitbuffer, ROR #16 AND tmp, mask, tmp, LSR #8 EOR bitbuffer, tmp, bitbuffer, ROR #8 ENDIF STR bitbuffer, [bitstream], #4 RSB bitsfree, bitsfree, #32 MOV bitbuffer, code, LSL bitsfree MOV pc, lr bitstream_write_flush RSBS bitsfree, bitsfree, #32 flush_loop MOVGT bitbuffer, bitbuffer, ROR #24 STRGTB bitbuffer, [bitstream], #1 SUBGTS bitsfree, bitsfree, #8 BGT flush_loop MOV pc, lr

■

6.7 Bit Manipulation

195

6.7.3 Variable-Width Bitstream Unpacking It is much harder to unpack a bitstream of variable-width codes than to pack it. The problem is that we usually don’t know the width of the codes we are unpacking! For Huffman-encoded bitstreams you must derive the length of each code by looking at the next sequence of bits and working out which code it can be. Here we will use a lookup table to speed up the unpacking process. The idea is to take the next N bits of the bitstream and perform a lookup in two tables, look_codebits[] and look_code[], each of size 2N entries. If the next N bits are sufficient to determine the code, then the tables tell us the code length and the code value, respectively. If the next N bits are insufficient to determine the code, then the look_codebits table will return an escape value of 0xFF. An escape value is just a flag to indicate that this case is exceptional. In a sequence of Huffman codes, common codes are short and rare codes are long. So, we expect to decode most common codes quickly, using the lookup tables. In the following example we assume that N = 8 and use 256-entry lookup tables. Example This example provides three functions to unpack a big-endian bitstream stored in a 6.25 bytestream. As with Example 6.24, these functions are not ATPCS compliant and will normally be inlined. The function bitstream_read_start initializes the process, starting to decode a bitstream at byte address bitstream. Each call to bitstream_read_code returns the next code in register code. The function only handles short codes that can be read from the lookup table. Long codes are trapped at the label long_code, but the implementation of this function depends on the codes you are decoding. The code uses a register bitbuffer that contains N + bitsleft code bits starting at the most significant bit (see Figure 6.7). bitstream look_code look_codebits code codebits bitbuffer bitsleft

RN RN RN RN RN RN RN

0 2 3 4 5 6 7

; ; ; ; ; ; ;

current byte address in the input bitstream lookup table to convert next N bits to a code lookup table to convert next N bits to a code length code read length of code read 32-bit input buffer (big endian) number of valid bits in the buffer - N

31 bitbuffer =

Figure 6.7

0 N bits

Format of bitbuffer.

bitsleft bits

0

196 Chapter 6 Writing and Optimizing ARM Assembly Code

tmp tmp2 mask

RN 8 ; scratch RN 9 ; scratch RN 12 ; N-bit extraction mask (1