Results 1 to 9 of 9
-
2021-04-03, 12:26 AM (ISO 8601)
- Join Date
- Dec 2005
- Location
- In the playground
xxxxxxxxxxxx
xxxxxxxxxxxx
Last edited by gooddragon1; 2023-01-07 at 09:54 PM.
There is no emotion more useless in life than hate.
-
2021-04-03, 01:51 AM (ISO 8601)
- Join Date
- Nov 2010
- Location
- California
- Gender
Re: [General Question] Smokey, this is not 'Nam, this is NASM
Not having tests? If the code is fancy and tricky, make lots of unit tests to make sure things are coming out the way you expect.
-
2021-04-03, 05:38 PM (ISO 8601)
- Join Date
- Nov 2006
- Location
- England. Ish.
- Gender
Re: [General Question] Smokey, this is not 'Nam, this is NASM
The specifics depend on the language(s) in use, but a few simple ones of the top off my head:
- Declare variables, even if your language creates variables on the fly - that way you know what datatype you are using.
- Give variables descriptive names, and don't re-use variables (less likely to happen if using descriptive names).
- Initialise variables before use.
- When putting together complex statements remember that the language compiler (or interpreter) may cast a variable or value (ie, change its apparant type) in an unexpected way.
- Make your code readable rather than trying to make it fast - tricks to speed up a program can trip you up.
- Break code out into procedures or functions for clarity. If you are repeating the same sections of code it may be worth breaking the code out into functions.
- Pay attention to code layout - indent things like loops and if statements - this helps make your code more readable, which really helps when trying to trace errors.
EDIT: ...And always take a save backup/copy of your code before you start making changes. In the case of serious error it is so much easier to revert to a known set of code than try and back out a complex set of edits.Last edited by Manga Shoggoth; 2021-04-03 at 05:47 PM.
Warning: This posting may contain wit, wisdom, pathos, irony, satire, sarcasm and puns. And traces of nut.
"The main skill of a good ruler seems to be not preventing the conflagrations but rather keeping them contained enough they rate more as campfires." Rogar Demonblud
"Hold on just a d*** second. UK has spam callers that try to get you to buy conservatories?!? Even y'alls spammers are higher class than ours!" Peelee
-
2021-04-03, 07:22 PM (ISO 8601)
- Join Date
- Feb 2015
Re: [General Question] Smokey, this is not 'Nam, this is NASM
I think NASM is probably the Netwide Assembler (and not National Academy of Sports Medicine), so, if assembly language hasn't changed in the decades since I had to work with it, it doesn't support any structured programming features. But it's probably a good idea to put really extensive comments in the code, that basically describe what the program is doing as if in a higher-level language. This includes listing your variables, whether static, stack-relative, or even other pointer-relative.
On a large programming project, with a good macro assembler, it's worth taking the trouble to define a set of macros that nearly emulate a compiler language. I don't know that NASM offers in that regard.
-
2021-04-03, 08:27 PM (ISO 8601)
- Join Date
- Dec 2005
- Location
- In the playground
Re: [General Question] Smokey, this is not 'Nam, this is NASM
Thank you for the replies. I'll see what I can do, it's a fairly small project so hopefully there won't be too many areas for problems. The commenting of the code is required. I'll have to start first of course to see what it's like...
There is no emotion more useless in life than hate.
-
2021-04-04, 03:24 AM (ISO 8601)
- Join Date
- Mar 2012
- Location
- UK
- Gender
Re: [General Question] Smokey, this is not 'Nam, this is NASM
As a software tester I find one of the main causes of bugs is when the customer's understanding of what they have asked for doesn't match the designer's or the developer's. Getting he requirements right is absolutely fundamental, but includes them not just being technically correct, but having everyone involved understand them in much the same way.
Last edited by Khedrac; 2021-04-04 at 03:24 AM.
-
2021-04-04, 05:49 AM (ISO 8601)
- Join Date
- Nov 2006
- Location
- England. Ish.
- Gender
Re: [General Question] Smokey, this is not 'Nam, this is NASM
Ah, Assembly Language.
Once I suppressed the flashbacks I dug out my old Z80 Machine Code books* to see if there was anything useful there - unfortunately not: It's mostly tecnical detail on programming. The old ZX81 Microprocessor Handbook** may have had something, but I have no idea where that book went.
However, from what I can remember about dealing with assemblers, my advice becomes:
- You declare memory locations rather than variables, but otherwise they work in a simillar way - make sure the declarations are the right size (very important with strings)
- Make your code readable rather than trying to make it fast - This is especially important in machine code as you are literally creating the loop and branch structures in machine code, rather than having a compiler do it for you.
- You will probbably be using jump (aka goto) and call (aka subroutine). There are many variants of jump and call for a given processor - make sure you use them correctly. If using labels for memory locations, use sensible labels (as per naming variables)
- Still pay attention to code layout - especially if you have to frame the brances and loops yourself - this helps make your code more readable, which really helps when trying to trace errors.
Above all else, when dealing with Assembly Code, don't rush into coding things. Fiddling with code in a 3GL or higher to get it right is very easy, but it becomes much harder in assembly, since something that is one or two lines of 3GL could take up a whole page of assembler.
* One of my two school prizes - The Greg Dale Drama Award (for work in the Sound an Light area); The other one was for Progress in Physics, which was the collected Lord of the Rings.
** The base ZX81 had less than 1K of usable memory for programming (16K with a memory expansion), and much of that went to supporting the display. You had to use machine code to get anything useful out of it...Warning: This posting may contain wit, wisdom, pathos, irony, satire, sarcasm and puns. And traces of nut.
"The main skill of a good ruler seems to be not preventing the conflagrations but rather keeping them contained enough they rate more as campfires." Rogar Demonblud
"Hold on just a d*** second. UK has spam callers that try to get you to buy conservatories?!? Even y'alls spammers are higher class than ours!" Peelee
-
2021-04-04, 04:00 PM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: [General Question] Smokey, this is not 'Nam, this is NASM
It's all pretty general but from what I remember of assembly:
1.Plan, then code.
2.If accepting user input, clean it before using it.
3.Put a limiter on loops where you don't explicitly control the iterations from the start.
4.It's ok if there are more comments than code.
All mostly because the further down the code-rabbit hole you go the less human readable things are and the harder it can be to track down errors. I also recall writing a program in something like C, then translating it into Basic, then down to assembly.
-
2021-04-04, 09:58 PM (ISO 8601)
- Join Date
- Jul 2010
Re: [General Question] Smokey, this is not 'Nam, this is NASM
If you really run into trouble coding a particular routine, you could always write it in C, compile it, disassemble the compiled machine code, and then annotate that. Or at least use it as inspiration / something to avoid depending on the results.