📄 hints.html
字号:
<!doctype html public "-//W3C//DTD HTML 3.2//EN"><html><head><title>Hints on assembler coding</title><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" /><meta http-equiv="content-language" content="en" /><meta name="resource-type" content="document"><meta name="copyright" content="This document copyright 2001 by Richard Murray. Use for non-profit and education purposes explicitly granted."><meta name="author" content="Richard Murray"><meta name="rating" content="general"></head><!-- /assembler/hints.html --><!-- --><!-- (C) Copyright 2001 Richard Murray --><!-- Designed by Richard Murray --><!-- rmurray@heyrick.co.uk --><!-- --><body bgcolor="#f0f0f0" text="#000000" link="#0022dd" vlink="#002288"><table border = "0" width="100%"> <tr> <td align=center width=100> <img src="arm3.gif" width=79 height=78 align = middle> </td> <td> <h1 align="center"><font color="#800080">Hints</font></h1> </td> <td align=center width=100> <img src="arm3.gif" width=79 height=78 align = middle> </td></table><p> <p><h2>Libraries</h2>Don't be afraid of libraries. In any 'language'. You see, you can either build a menu or windowfrom scratch every time you need it, and calculate the length of a string on the fly, or you canmake like easier (and, seemingly paradoxically, your code smaller) by utilising libraries.<p>One thing that I do recommend you do is take the time to work through your library code and debugit. Very few libraries are entirely 'bug free', and the last thing you need is to spent a longtime trying to resolve a quirk in your code that originates in a library.<br>To give an example, the wonderful image conversion software <i>ChangeFSI</i> will error whenloading a certain type of TIFF file. This is not a fault of a library. I have not patched my copybut if I remember correctly, it is the result of a simple typo in a piece of code that is onlyused under certain conditions. Now, it will seem - to a programmer - to be a fairly trivial thingbut the same can happen with library code. So save yourself trouble, and make sure the libraryis bang on spec before you use it.<p> <p><h2>Backup</h2>Backup regularly. It is possible, if you do something foolish like blanking a file full of code,to recover the <i>lost</i> data from the now-unused part of your harddisc. But I would not relyupon it. I know this from experience. Also, scanning many megabytes of data looking for the rightbits is not a job I'd wish on my mortal enemy. I had to recover a lot of stuff from a failed512Mb partition. Trust me, you do <i>not</i> want to do that.<p>So. Backup your data. I know you won't back up daily. Heck, I don't do it - and I've had enoughdisasters to convince me I should. But what I have done is to write a program to extract thesourcecode and resources from my projects and copy them to an iomega zip disc. This, done weekly,is - as far as I can see - good backup. If you use the 'Newer' Copy option, it flies along.<br><i>(the program is called '!AutoBack', it is not polished, but if you would like a copy...)</i><p>Remember, you don't need to keep executables. If you do not have sufficient data to generate afull executable, then you aren't copying enough. I copy across only the current development notesand sources and resources. From that, the executable can be built.<br>If is a good idea to make a copy of the assembler/compiler/linker and any tools that you use.Ignore what the software licence conditions say, you ARE (under EU law (assuming you live in theEU, pity our US readers!)) entitled to make reasonable software backups. I consider a bare-bonescopy in your source backup as being 'reasonable'. Anybody who doubts me, consider getting holdof, say, objasm 2.00 or Norcroft C version 4. Good luck!<p>Try a CD-ROM burner. They'll hold 650Mb. While they are a one-shot media, and not reallyupdatable, they're a damn sight cheaper than most other methods of storing data, they arereliant, and the storage capacity has a lot going for it. You can then just dump your ENTIREcoding partition/drive onto a CD-ROM.<br>But don't be cheap. Keep a weekly backup cycle going. Use the previous discs for reference forearlier copies of the software. Failing that, Maplin sell clock mechanisms cheaply. Turn yourold CDs into clocks and give them to your parents!<br>If you are really paranoid about source issues, stick your old CD in a microwave oven, for abouttwo and a half seconds (650W). Of course, I won't be liable if anything blows up, but on the upside, nobody will read that CD ever again...<p>Always keep a backup <i>with you</i>. My site backup is held on a small harddisc slung out theback. The zip disc lives in my backpack. If I used CD-ROMs, I'd bury one a month in the garden.It may sound like I've lost my mind - but think if your equipment catches fire. Nobody wants tothink about situations like that, but can happen, as can a total disc failure. And it helps tohave thought about it, and considered your options.<br>While a disc failure can, to a large extent, be cured by fitting a new drive (or, in extremecases, buying a new computer) and installing from backup... I can't think of a feeling worse thannot only losing all of your equipment and possessions, but also the realisation that all of yourdata is gone. For me, that would mean a serious chunk of the last decade of my life. Thus, Iensure that a copy of the important stuff goes where I go. Now, I can be involved in a seriousRTA and also a fire; which would take care of both copies; but I kinda figure in that case, mydata would probably be immaterial!<p> <p><h2>Source releasal</h2>When you officially abandon a project, release the source into the public domain. Maybe it'll beignored, maybe you'll help a newbie learn, maybe those people that use your software will beable to maintain it themselves.<p>I have an agreement with a friend that upon my untimely demise, he will interrogate my computerand my backups and make <i>all</i> of my non-commercial programming fully public.<br>You see, the way I see it is that companies and individuals stop coding - for whatever reason,from death to a change in life (like they got married and don't have time for it) to they simplyadandoned the platform - and they take with them a lot of source.<br>Consider Computer Concepts. They left the RISC OS market and took with them several incarnationsof a highly rated desktop publisher, and an artwork design program. All of their code was inassembler, so it'd probably be hellish to work through. However had they released the code to theopen source concept, then I'm sure somebody would keep the software alive; more so than thecurrent addition of plug-ins.<br>It just seems, to me, to be a terrible shame to squander all of that time and development. Afterall, if you are leaving, what do you have to lose by making your old code Open Source? Let yourlegacy live on.<p>I wish to point your attention to<a href="http://www.drobe.co.uk/codevault/">http://www.drobe.co.uk/codevault/</a> <font color = "red" size = "-1">[EXTERNAL LINK]</font>. It isn't chockfull of legacy code available for programmers to update and maintain, but it is a damn goodstart!<br>I wish to congratulate everybody who has had the foresight and vision to make their older sourcecode publically available, and I hope that soon more companies will make their oldno-longer-maintained software available for enthusiast programmers to develop.<p> <p><h2>Debugging</h2>Somewhere I read that 10% of time is spent coding, and 90% is spent fixing the code.<br>When you write in BASIC or C, you are speaking to the machine in a pseudo-english language. Ithas strict rules, but <i>if...then...else</i> is fairly easy to follow.<br>With assembler, you are speaking to the machine more in its own language. The nmemonics areprovided to assist you (the computer doesn't actually understand 'STMFD', it still undergoes atranslation), however now we are at a state where every instruction you type translates to oneprocessor instruction. Where concepts such as strings and arrays cease to exist. Few of you willbe programming the <i>bare metal</i> (ie, generating text by poking data directly into memoryand communicating directly with hardware - this is mainly an art that is part of operating systemand/or device driver design), but you are still operating at a much lower level. You have thefull gamut of access to the system, you have the ability to fiddle with hardware in a way thathigh level languages only dream of. The entire computer is your oyster.<p>This brings with it a severe penalty. That of responsibility. Now Linux users will advocate thata user program should never be able to access supervisor mode. Likewise, you should not be ableto stiff the machine with one instruction. That's all very well and proper on their Linux. Thatis not RISC OS. My personal feelings are that RISC OS is more of an enthusiasts operating system.Sadly, source code is not available (one big plus for Linux), but RISC OS almost goes out of itsway to provide full and uninhibited access to the machine.<p>Thus, you must be responsible.<p> <p>When you code in a high level language, it may not work first time.<br>When you code in assembler, I'd be surprised if it worked first time. I knocked up a little bitof code to scan and load Fresco cache files (part of<em>QuickVoy</em>) and I was very surprised that it workedflawlessly the very first time.<br>Don't be discouraged - it is very simple to make a mistake in something as deep as assembler. Itis all part of the process. It is a learning process. Every time you track down that bug, youhave discovered a little bit about yourself, and about the inner workings of the machine.<br>If your bug is a silly mess up on your part, you'll need to try harder next time!<br>But if your bug is one of those subtle I-spend-three-days-on-this problems that stems from deepwithin the system itself, then don't fix it and carry on fixing. That's bad. Fix the deep bug,then take a moment. Think about the mental obyssey you just took. And for God's sake be sure topat yourself on the back. Those big obscure ones are the worst. And when you are in the zonechasing it, you are no longer thinking like a <i>code monkey</i>, you have become a <i>hacker</i>and you are meeting the hardware and firmware on its own terms. Very little may change as far asan observer can see, but inside your mind, incredible things happen. So always be sure to take amoment. It is moments like that that make it worthwhile.<p>Chances are, if you are reading this, it is because you do this by choice - not because youremployer expects you to. So you have some inclination of what I'm on about. If you do not, thendon't be afraid to try!<p>Maybe I'm totally mad, but I find the very worst thing is a blank !Zap window awaiting me to typein some code. It actually depresses me. I much prefer to add to existing code, to optimise code(either in the HLL, or by adding chunks of assembler to speed things up), or by debugging.<p> <p>Failures can be categorised into one of three types...<p><b>It totally fails</b><br>This is probably the simplest to fix. This is because something glaringly obvious is going wrong.<ul> <li> Forgetting to set <tt>P%</tt> (or <tt>O%</tt>) and/or the <tt>OPT</tt>ions before entering assembler. <br> <br> <li> Forgetting to <tt>CALL</tt>, or mixing up parameters passed to <tt>CALL</tt>/<tt>USR</tt>. <br> <br> <li> No <tt>MOV PC, R14</tt> return, if required. <br> <br> <li> Alternatively, corrupting <tt>R14</tt> accidentally. <br> <br> <li> Is BASIC whinging about corrupt R13/stack pointer?<br> If so, check you aren't setting R13 to the result of SYS OS_GetEnv like you would for an application. BASIC sets R13 appropriately for you, and sulks if it isn't as expected when you exit. <br> <br> <li> Only passing through the assembler once when two passes were required (to resolve forward references).</ul><p><b>Something is happening, but not what it supposed to happen...</b><br>This is harder to fix, and may be due to:<ul> <li> Incorrect address used to load/store data - is the <tt>ADR</tt> offset within range? <br> <br> <li> Did you enter a hex. address and miss out the & denotation? <br> <br> <li> Using a register without preserving its contents. Under APCS, doing this to any register other than <tt>a1</tt> to <tt>a4</tt> (<tt>R0 - R3</tt>) can result in all sorts of general weirdness later on down the line. <br> <br> <li> Incorrect use of the stack. Unless you are using APCS stack frames, basically what goes in is what must come out. Note that while you can store R14 and reload it into R15, you cannot use the stack as: <code>STMFD R13!, {R0, R1}<br> LDMFD R13!, {R1, R0}</code><br> as the registers are stored in order, so R1 and R0 would be swapped into correct order.</ul><p><b>It <i>nearly</i> works...</b><br>This is a hard one to fix, as the errors are going to be a lot more subtle. Some ideas...<ul> <li> When shifting, you are off by one. <br> <br> <li> Conditional instructions proceeded by a mathematical operation in which the <tt>S</tt> bit should have been set, but wasn't. <br> <br> <li> One off in a count (ie, you counted 1 to 10, not 0 to 9). <br> <br> <li> Mixing up LT (less than) condition code with LE (less than or equal). Likewise GT and GE. <br> <br> <li> The wrong kind of addressing for load/store, or incorrect use/type of writeback. <br> <br> <li> Forgetting to set a register to a specific value that you later rely on. <br> <br> <li> Wrong processor mode. <br> <br> <li> Overrunning the allocated space available for your code. <br> <br> <li> Not setting the stack pointer (if required) at the start of your program. <br> <br> <li> Using the wrong kind of stack. RISC OS convention is for a Fully Descending stack. It is advisable to use the same. <br> <br> <li> Calling a SWI and not setting up all of the correct registers.<br> Alternatively, not taking into account which registers the SWI updates/corrupts.</ul><hr size = 3><a href="index.html#06">Return to assembler index</a><hr size = "3"><address>Copyright © 2001 Richard Murray</address></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -