Announcement

Collapse
No announcement yet.

Assembly Language Bytes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Assembly Language Bytes

    I am working on a debugger, and have gotten a LONG way thanks to Paul Dixon pointing things out how Assembly Language works (thankfully I had some exposure to assembly about 15 years ago).

    Anyways, one thing that keeps cropping up is how do I tell a break between lines of code (or between instructions)? Is it a null byte? or some other flag indicating that the next byte is a new command?

    Also is a break in assembly = a break in code? IE: if I had the following, (and this is bogus code)
    Code:
    MSGBOX "Hello"
    If assembly was really
    Code:
    PUSH something
    MOVE something
    DANCE
    POP something
    4 lines does not = 1 line, but I can work on that. For now I am just trying to figure out the breaks between lines
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    4 lines does not = 1 line, but I can work on that. For now I am just trying to figure out the breaks between lines
    Um, that's what the PowerBASIC compilers do... translate "English-like" words and lines (aka 'source code') into machine code.

    I suppose you could ask Mr. Zale for the details of exactly how PowerBASIC converts source code into executable code, or exactly what is included in the RTL and how those RTL functions are called, but I will make a guess he will suggest that if you want the company's confidential and trade secret property, you will first have to buy the company.


    MCM
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Cliff,
      there is no break between instructions.
      If you correctly disassemble one instruction then the next byte is the first byte of the next instruction.

      Paul.

      Comment


      • #4
        Um, that's what the PowerBASIC compilers do... translate "English-like" words and lines (aka 'source code') into machine code.
        Ummmmm....like Yuuuuuhhhhh, I would think that to be self evident.

        I suppose you could ask Mr. Zale for the details of exactly how PowerBASIC converts source code into executable code, or exactly what is included in the RTL and how those RTL functions are called
        I suppose I could, if I were out to write a crummy bug ridden compiler that comes no where close to the quality of product that PB provides. (Much like M$ and other compilers I have seen).

        But that is not the point, nor what I am attempting to do.

        I am just simply trying to understand better how Assembly relates to "Basic" and the Docs I see are convoluted with instructions like.

        Directions ---> Find a peice of info here --->then directed to manual 5 chapter 23

        Manual 5 chapter 23 ---> Find a peice of info here --->then directed to manual 2 chapter 8

        Manual 2 chapter 8 ---> Find a peice of info here --->then directed to manual 1 chapter 2 and look up a table to find the next link to the next manual.

        and so on........

        GAHHHHHHhhhhh ..... whoever writes those things certainly never had to work with them.

        And simply, I just wanted to figure out how many bytes on a line, so I could increment a pointer that many bytes, and execute the next line (or skip a few lines, and then continue)
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          Thank you Paul

          I was guessing a null byte or something, as apparently my first attempts are amiss. Since I keep running into opcodes that I can not locate in documentation.

          Back to the drawing board. And ripping my hair out
          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            Cliff, have you tried using Ollydbg (olly debug)? You can write a little code, then look at what it compiled to, then you can change your code, continue writing more, or whatever you like.

            Try this in ollydbg and watch the compiled code execute step by step.
            Code:
            #COMPILE EXE
            #DIM ALL
            #OPTIMIZE SIZE  'avoids !nops you don't place in yourself
            
            FUNCTION PBMAIN () AS LONG
                LOCAL b AS BYTE, n AS LONG
                n = 322994939
                !int 3  ;stop point. Comment or remove before running outside ollydbg or illegal oper. will occur.
                !nop
                !nop
                !nop
                !nop
                b = LO(BYTE,n)
                !nop
                !nop
                !nop
                !nop
            
            END FUNCTION
            Last edited by John Gleason; 13 Jun 2009, 03:02 PM. Reason: correct comment

            Comment


            • #7
              And simply, I just wanted to figure out how many bytes on a line, so I could increment a pointer that many bytes, and execute the next line (or skip a few lines, and then continue)
              Thre is precisely zero relationship between a line of source code and the number or size of the instructions generated by the compiler for that line of source code.

              But.... you can use labels and CODEPTRs if you want to get the SIZE......

              Code:
              A:
                 LET B=2:  Z =  12 * Y  :  Q =SQR(13) 
              B:
                PRINT B
              The size of the instructions generated by line "A" is CODEPTR(B) - CODEPTR(A). Note, however, those instructions might include CALL and/or JMP, so it's not a measure of the size of the code actually executed when travelling from "A" to "B" .. it's the size of the machine code which happens to be stored between "A" and "B"
              Last edited by Michael Mattias; 13 Jun 2009, 06:14 PM.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Thre is precisely zero relationship between a line of source code and the number or size of the instructions generated by the compiler for that line of source code.
                I got that (especially with all the trials I have done).

                What I did not get was where the break occurs. Thank you to Paul for pointing out there is no break. (Now I at least understand that trying to "reverse-engineer" my own code at runtime, is not as simple as I 1st thought)

                although "Reverse-Engineer" may be a bad choice of words, but its essentially what I am doing to debug my own code.

                Finally I am starting to understand (nothing like a good brick to the side of the head to see tweety-birds) that maybe (just maybe) I can figure out one of my most complicated things to achieve.
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                Comment


                • #9
                  I suggest taking a look at an DOS old basic compiler called BASM286. It can be found here:
                  http://www.bcxgurus.com/

                  You write programs in a very simplified basic and it generates assembly language files that you can then assemble and link to generate your program.

                  For your purpose you won't really need the assembler and linker, although you might want to play with that, too. You can write some basic code and see exactly what assembly is generated.

                  One of the reasons I think this might be particularly useful is that it doesn't use any library code. Everything is generated inline.

                  The basic in BASM isn't a lot like PB and the assembly code generated is 286 assembly, which is a subset of the code PB would generate but none of that matters. If you just want to get an understanding of the relationship of the source to the assembly code this is a good way to do it.

                  Barry

                  Comment

                  Working...
                  X