Assembly Language Bytes

[Cliff Nichols]

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)

MSGBOX "Hello"

If assembly was really

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

[Michael Mattias]

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

[Paul Dixon]

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.

[Cliff Nichols]

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)

[Cliff Nichols]

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

[John Gleason]

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.

#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

[Michael Mattias]

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

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"

[Cliff Nichols]

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.

[Barry Marks]

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