Have noticed that .hex files produced by GCASM are not identical to those produced by MPASM, when using .asm source file generated by GCB compiler. Wondering if this is ever important in terms of the functioning of the code after flashed to the PIC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Probably not. Depends on what is different but sometimes it's just the way unused bits are coded that makes the hex files different but have no effect on the PIC operation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main difference is in the formatting. GCASM tries to put 16 bytes on each line, MPASM tries to make every address a multiple of 0x0010. So the first few lines of a program from MPASM are:
The actual machine code that gets downloaded to the PIC for each is identical in these cases.
There are a couple of other minor differences - clrw is different. There are some bits in this that are "reserved" and should be set to 0 according to the datasheet, which GCASM does. For some reason, MPASM sets these 3 bits high. Also, program memory addresses in MPASM get 0x8000 added to them if used with the high and low operators, but are left unchanged by GCASM. The compiler takes this into account. And finally, if a CONFIG register is set to 0xFF, MPASM will explicitly state this in the hex file, but GCASM doesn't. That's the default value for a blank address, so there's no need to. Otherwise, everything should be the same.
Since October last year, I've had a test program that compiles and assembles about 300 programs I've collected from this forum and from emails over the years. It does a few things, including checking that the hex code produced by GCASM matches that produced by MPASM or avrasm2. So if you get something that doesn't work, and the hex code doesn't match, there could be a problem. But if the hex code looks different and it still works, don't panic!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-05-05
One difference that drives me crazy is this. When putting together a table, the compiler creates a one-line .DE statement. It can get quite long! GCASM doesn't mind, but MPASM gives up after 80 bytes (if memory serves). It simply truncates and dumps the remainder of the line.
Two wishes: first, I wish the compiler would break up huge lines into chunks. This not only is easier to read without scrolling left and right like wild, but also keeps MPASM happy.
Second, and slightly related: I wish the TABLE command could handle entries horizontally. In this case, it's the scrolling up and down that drives me nuts. One entry per line leads to some very long source code and is also harder to read.
But back to Jack's original concern: look out for long tables.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have noticed that .hex files produced by GCASM are not identical to those produced by MPASM, when using .asm source file generated by GCB compiler. Wondering if this is ever important in terms of the functioning of the code after flashed to the PIC.
Probably not. Depends on what is different but sometimes it's just the way unused bits are coded that makes the hex files different but have no effect on the PIC operation.
The main difference is in the formatting. GCASM tries to put 16 bytes on each line, MPASM tries to make every address a multiple of 0x0010. So the first few lines of a program from MPASM are:
And the first few from GPASM are
The actual machine code that gets downloaded to the PIC for each is identical in these cases.
There are a couple of other minor differences - clrw is different. There are some bits in this that are "reserved" and should be set to 0 according to the datasheet, which GCASM does. For some reason, MPASM sets these 3 bits high. Also, program memory addresses in MPASM get 0x8000 added to them if used with the high and low operators, but are left unchanged by GCASM. The compiler takes this into account. And finally, if a CONFIG register is set to 0xFF, MPASM will explicitly state this in the hex file, but GCASM doesn't. That's the default value for a blank address, so there's no need to. Otherwise, everything should be the same.
Since October last year, I've had a test program that compiles and assembles about 300 programs I've collected from this forum and from emails over the years. It does a few things, including checking that the hex code produced by GCASM matches that produced by MPASM or avrasm2. So if you get something that doesn't work, and the hex code doesn't match, there could be a problem. But if the hex code looks different and it still works, don't panic!
One difference that drives me crazy is this. When putting together a table, the compiler creates a one-line .DE statement. It can get quite long! GCASM doesn't mind, but MPASM gives up after 80 bytes (if memory serves). It simply truncates and dumps the remainder of the line.
Two wishes: first, I wish the compiler would break up huge lines into chunks. This not only is easier to read without scrolling left and right like wild, but also keeps MPASM happy.
Second, and slightly related: I wish the TABLE command could handle entries horizontally. In this case, it's the scrolling up and down that drives me nuts. One entry per line leads to some very long source code and is also harder to read.
But back to Jack's original concern: look out for long tables.