PDA

View Full Version : PBP, ASM and LST files



HenrikOlsson
- 11th January 2010, 19:56
Hi,
I'm trying to find what ASM code PBP produces for a specific routine. I'm doing this for two reasons:
1) To learn more about ASM and how PBP works and
2) To find out which system variables and registers the routine may use. (So I can save only the needed ones during a "PBP ASM interrupt")

For example, I compile this code:


If PIR1.5 THEN
RxBuffer[RxPtr] = RCREG
If RxBuffer[RxPtr] = 13 THEN
ReceivedCR = 1
ENDIF

RxPtr = RxPtr + 1

If RxPtr = BufferLength THEN
RxPtr = 0
ENDIF


Looking at the bottom of the generated ASM file I find this:

AIN?BBB RCREG, _RxBuffer, _RxPtr
AOUT?BBB _RxBuffer, _RxPtr, T1
CMPNE?BCL T1, 00Dh, L00003
MOVE?CT 001h, _ReceivedCR
LABEL?L L00003
ADD?BCB _RxPtr, 001h, _RxPtr
CMPNE?BCL _RxPtr, _BufferLength, L00005
MOVE?CB 000h, _RxPtr
LABEL?L L00005
LABEL?L L00001

END

This doesn't look much like the ASM I've seen before.... ;-) But between the above ASM file and the LST file I think I've come to the conclusion that I need to save T1 and the FSR0 registers for the above PBP code to work as an "ASM interrupt" without disturbing the PBP main program. Or is it not that "simple"?

I guess my question is: Is there a way to get a file containing only the ASM code that will actually generate the final .hex file and not all the "extra" that is in the LST file?

Thanks!
/Henrik.

mackrackit
- 11th January 2010, 22:43
Yup, the ASM produced by PBP looks a little strange but that is it.

If you take the ASM from PBP and compile it in MPLAB it will make a HEX.

Art
- 11th January 2010, 23:22
That isn't the way a Human writes an assembler program.
To get a useful assembler source code, download ICprog for free here:
http://www.ic-prog.com/

Open your hex file and select "assembler" under the "View" tab.
It only works for 16 family devices (I think) I can guarantee it works with
16F84/A, 16F628/A, 16F876, 16F877 hex codes.

You'll notice you can only directly look at logic operations such as IF-THEN
statements, NEXT-FOR loops, maths operations, etc.

If you use any functional commands such as SOUND, LCDOUT, I2CREAD, etc.
PBP inserts the code/libs for these commands at the start of the assembler source,
and then each PBP command calls that code.

For example, if you use the SERIN command three times in your PBP program,
the assembler serial code is only inserted once (a simple routine that receives one byte),
and the program calls that routine to receive every byte (around the areas of the program
that each SERIN command was).

You can save memory there because PBP uses some unnecessary "transporter variables" to
deliver values to these libraries. With some study, in assembler, you can use them directly.
Cheers, Art.

Gusse
- 11th January 2010, 23:30
Hi,

After first trials with PBP I also checked ASM-file made by PBP and I was very puzzled. Then I found this old thread (asm and pbp (http://www.picbasic.co.uk/forum/showthread.php?t=539)), which explained these strange strings (list of macros).

BR,
-Gusse-

HenrikOlsson
- 12th January 2010, 06:31
Thanks guys,
I know how the toolchain works, PBP compiles to ASM (sort of) and MPASM assembles that file creating a .hex file. I was hoping I somehow could get an ASM file containing only what will actually get assembled after all the assembler directives etc have been parsed/evaluated and the macros "called" have been replaced with the actual ASM code.

Oh well, the routines I'm trying to figure out here are fairly simple, like in the example I posted. Between the ASM, LST and MAC files I think and hope I can figure it out.

Darrels wonderful interrupt routines saves all the PBP system variables and in my case that just takes too much time. So, I'm trying to figure out what variables are being used by my routines so I can save those and only those.

Disassembling the hex file won't do me much good as I then have lost all variable names etc.

Thanks!
/Henrik.

Art
- 12th January 2010, 13:43
Disassembling the hex file won't do me much good as I then have lost all variable names etc.

That's not very imaginative. Add this to your PicBasic code and disassemble it:



@ nop
@ nop
@ nop
Variable_Name = Variable_Name
@ nop
@ nop
@ nop


and it will be easy to find in the assembler code, even if it is renamed.
Art.