Support the GITP forums on Patreon
Help support GITP's forums (and ongoing server maintenance) via Patreon
Results 1 to 9 of 9
  1. - Top - End - #1
    Troll in the Playground
     
    gooddragon1's Avatar

    Join Date
    Dec 2005
    Location
    In the playground

    Default [General Question] Smokey, this is not 'Nam, this is NASM

    ... there are rules.

    To avoid a world of pain, is there any particular thing I should look out for as a common thing that causes bugs? I'm going to have to do a project and while I'm not a fan of low-level languages, it's what's being asked for. It's a super simple project (some basic math), but low-level languages are tedious (at least for me).
    Last edited by gooddragon1; 2021-04-03 at 12:31 AM.
    There is no emotion more useless in life than hate.

  2. - Top - End - #2
    Barbarian in the Playground
     
    OldWizardGuy

    Join Date
    Nov 2010
    Location
    California
    Gender
    Male

    Default 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.

  3. - Top - End - #3
    Ogre in the Playground
     
    Flumph

    Join Date
    Nov 2006
    Location
    Essex, England
    Gender
    Male

    Default 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

  4. - Top - End - #4
    Barbarian in the Playground
     
    MindFlayer

    Join Date
    Feb 2015

    Default 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.

  5. - Top - End - #5
    Troll in the Playground
     
    gooddragon1's Avatar

    Join Date
    Dec 2005
    Location
    In the playground

    Default 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.

  6. - Top - End - #6
    Troll in the Playground
     
    PaladinGuy

    Join Date
    Mar 2012
    Location
    UK
    Gender
    Male

    Default 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.

  7. - Top - End - #7
    Ogre in the Playground
     
    Flumph

    Join Date
    Nov 2006
    Location
    Essex, England
    Gender
    Male

    Default Re: [General Question] Smokey, this is not 'Nam, this is NASM

    Quote Originally Posted by DavidSh View Post
    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.
    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

  8. - Top - End - #8
    Troll in the Playground
     
    Telok's Avatar

    Join Date
    Mar 2005
    Location
    61.2 N, 149.9 W
    Gender
    Male

    Default 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.
    Niven's Laws, #5
    If you've nothing to say, say it any way you like. Stylistic innovations, contorted story lines or none, exotic or genderless pronouns, internal inconsistencies, the recipe for preparing your lover as a cannibal banquet: feel free. If what you have to say is important and/or difficult to follow, use the simplest language possible. If the reader doesn't get it then, let it not be your fault.

  9. - Top - End - #9
    Ogre in the Playground
     
    gomipile's Avatar

    Join Date
    Jul 2010

    Default 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.
    Quote Originally Posted by Harnel View Post
    where is the atropal? and does it have a listed LA?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •