• AVR Freaks

AnsweredHot!XC8 PIC-AS insights

Author
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
2021/01/28 05:18:23 (permalink)
5 (2)

XC8 PIC-AS insights

Background
 
I am adapting Great Cow BASIC to support PIC-AS.  We a few 1000 baseline programs that work with Great Cow BASIC (an they work on real silicon), however, we need to add PIC-AS support for training and debugging.
 
These issues are reported to Microchip and they are working them.  But, some will impact folks porting ASM to PIC-AS.  I will add more as I progress with the work.
 
So, I am not looking for fixes as engineering are working these issues, but, I am sharing these insights.  
 
If you have more insights - do add.
 
Evan
 
----
Reserved Labels
 
Labels are reserved within the ELF debugger means that you cannot use these labels within PIC-AS .S source
 
This issue relates to the use of labels such as `LINE:`, `HEX:`.   You can create the label (and code sections) but you cannot `call`.
 
Considering that `LINE:`, `HEX:` are typically used with GLCD solutions this has a huge impact to our project.
There are other reserved words like `FILE`. I am determining the full impact via regression testing.
 
I have fed back to engineering that this needs to be changed as the impact may be large.
 
 
----
Memory reporting
 
This issue relates the reporting of memory used.  The following simple example show the reporting to be incorrect.  There is a secondary issue relating to memory reporting when using ABSolute mode.
 
#include <xc.h>
PSECT myDATA,class=BANK0,space=1
GLOBAL myVar
myVar: DS 2
 
PSECT text,class=CODE,reloc=2
main:
 movf myVar,w
 movwf 20
Engineering are investigating these issues.
 
----
MPLAB-X Simulator/Debugging
 
This is relates the disassembly for PIC-AS source compiled ONLY by MPLAB-X.  This disassembly is incorrect for a valid PIC-AS source.  
 
Example ADCON is not disassembled, but, some other register.  This is NOT a banksel issue. 
 
This issue does impact the operation of debugger but it will lead to folks looking as the disassembly wondering what is actually happening.
 
----
Specification of processor type - twice.
 
Currently, you are required to specify the processor type twice.  Once within the source, and, again on the command line.
 
There are use cases where the new PIC-AS toolchain should accept only one specification of the processor type.  These use cases are valid and Microchip engineering are looking into the resolution.
 
Meanwhile - specification of processor type is needed twice.
 
post edited by Anobium - 2021/01/28 05:22:33
#1
mad_c
Super Member
  • Total Posts : 1289
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: online
Re: XC8 PIC-AS insights 2021/01/28 12:57:54 (permalink) ☼ Best Answerby Anobium 2021/01/28 13:13:43
+1 (1)
Anobium
Currently, you are required to specify the processor type twice.  Once within the source, and, again on the command line.

That's not correct. You only have to specify it once, and that is always using the command line option. You have the choice to also use the PROCESSOR directive inside the source if you want to ensure that no one tries to compile the code for a different device than you intended. It will generate an error if the device specified with it does not agree with the command line option. You could also use preprocessor directives to do the same thing.
 
Jeff.
#2
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/28 13:23:13 (permalink)
0
@Mad_c   You are correct.
 
The use case is specific where the processor type IS passed from the IDE to the PIC-AS.exe.   I have just change the IDE to NOT use the -mcpu=%ChipModel%   on the command line and I get:
 
(2042) no target device specified; use the -mcpu option to specify a target device
 
The .S is consistent with 
 
;Set up the assembler options (Chip type, clock source, other bits and pieces)
PROCESSOR 18F16Q41
PAGEWIDTH 132
RADIX DEC
TITLE "D:\Great-Cow-BASIC-Demonstration-Sources.git\trunk\Vendor_Boards\Great_Cow_Basic_Demo_Board\18f16q41_chiprange_demonstrations\160_showing_eeprom_data_to_serial_terminal.S"
SUBTITLE "01-28-2021"
 
I did can remove the PROCESSOR 18F16Q41 retaining the  -mcpu=%ChipModel% and this does work.
 
Now, I am puzzled.  As Microchip support have accepted this as an issue.
 
Thank you for clarifying.
#3
mad_c
Super Member
  • Total Posts : 1289
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: online
Re: XC8 PIC-AS insights 2021/01/28 13:40:42 (permalink)
0
Anobium
@Mad_c   You are correct.
 
Now, I am puzzled.  As Microchip support have accepted this as an issue.

I am not aware of what transpired, but possibly they think the 'issue' is that the documentation be made more clear.
 
Jeff.
#4
mlp
boots too small
  • Total Posts : 1005
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/28 13:41:58 (permalink)
-1 (1)
Anobium
@Mad_c   You are correct.

He usually is. He wrote much of the code and most of the manual.

Mark (this opinion available for hire)
#5
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 03:40:04 (permalink)
0
Posting more information on the errant OpCodes.  It turned out to be something far more serious.
 
The genereted HEX from PIC-AS does not operate as expected - with a reset occurring.  So, this is a real issue. 
 
PIC-AS is not correctly handling the generation of the code. PIC-AS is placing opcodes incorrectly.  Which causes whole segments of code to be misplaced by one byte.
 
The picture shows the issue.
 

The left hand disassembly shows the errant handling, and, for comparison the right hand disassembly shows what it should be.
 
Formally reported this on Tuesday and I have updated the record with this is updated information today.  But, something is not correct as MPASM does not do this.....
post edited by Anobium - 2021/01/30 03:44:06

Attached Image(s)

#6
NorthGuy
Super Member
  • Total Posts : 6518
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 11:06:50 (permalink)
+2 (2)
AnobiumThe left hand disassembly shows the errant handling, and, for comparison the right hand disassembly shows what it should be.



The code is completely different, nothing in common. Looks like PIC-AS placed a completely different section to this place, while the section you expect to be there is probably somewhere else.
 
#7
dan1138
Super Member
  • Total Posts : 4242
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 12:06:56 (permalink)
+1 (1)
Anobium
Formally reported this on Tuesday and I have updated the record with this is updated information today.  But, something is not correct as MPASM does not do this.....

The pic-as assembler at its core uses an architecture independent design. To implement this Hi-Tech used a flexible but complex way for the assembly source code to describe how the target code and data space is to be filled by the binary objects generated by the assembler. The way MPASM handles memory is not this complex and unlike pic-as you cannot tell MPASM to do bad things with section declarations.
 
From the fragment you posted it not possible to see but this looks like the psect that the pic-as is generating code into is not declared correctly for the kind of controller the code is intended to build for.
#8
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 12:45:57 (permalink)
0
This is related to the correct alignment of code  after databytes (tables),  as the code is in ABS.   At the moment to resolve... put one extra byte in the databyte(table) and this will correct the code.
 
 
#9
1and0
Access is Denied
  • Total Posts : 12086
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 13:00:07 (permalink)
+1 (1)
NorthGuy
The code is completely different, nothing in common. Looks like PIC-AS placed a completely different section to this place, while the section you expect to be there is probably somewhere else.

The code is off by one byte.
#10
1and0
Access is Denied
  • Total Posts : 12086
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 13:03:41 (permalink)
+1 (1)
Anobium
This is related to the correct alignment of code  after databytes (tables),  as the code is in ABS.   At the moment to resolve... put one extra byte in the databyte(table) and this will correct the code.

As I've said numeric times before, PIC-AS requires too much detail handling from the users. Settings like "reloc", "delta", and so on should be defaulted and predefined once the PIC device is specified.
#11
NorthGuy
Super Member
  • Total Posts : 6518
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/30 22:21:16 (permalink)
0
1and0
NorthGuy
The code is completely different, nothing in common. Looks like PIC-AS placed a completely different section to this place, while the section you expect to be there is probably somewhere else.

The code is off by one byte.



It is.
#12
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/31 11:14:29 (permalink)
0
Advice please.
 
I need to resolve this instruction alignment issue asap.  So, what file contains the lst, like the example below:
 
I have the HEX, O, I, S, ASM, ERR, ELF, MAP, CFM from PIC-AS.  But, unless I am mistaken I cannot find a lst - I truly may have overlooked.  
 
Any advice ?
 
Evan
 
000556 0E02 MOVLW 2
       0114 BANKSEL SYS_HEXPICAS_0
00055A 6F8F MOVWF SYS_HEXPICAS_0,BANKED
00055C 0E0F MOVLW 15
00055E 142B ANDWF SYSVALTEMP,W,ACCESS
....
#13
1and0
Access is Denied
  • Total Posts : 12086
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: XC8 PIC-AS insights 2021/01/31 11:51:10 (permalink)
+1 (1)
Anobium
I need to resolve this instruction alignment issue asap.  So, what file contains the lst, like the example below:
 
I have the HEX, O, I, S, ASM, ERR, ELF, MAP, CFM from PIC-AS.  But, unless I am mistaken I cannot find a lst - I truly may have overlooked.  
 
Any advice ?

Add the command line option -Wa,-a to generate a list file.
#14
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/02/01 06:11:46 (permalink)
0
Thank you.
 
The lst shows the errant code at the correct address, but, the HEX is not correct.   The lst file has helped isolate the issue to the HEX generation process within the toolchain.
 
I have passed the new information to support.
 
#15
ChrisFox
Junior Member
  • Total Posts : 26
  • Reward points : 0
  • Joined: 2020/12/03 09:11:48
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/02/02 20:39:54 (permalink)
0
There are many bugs in PIC-AS. Not to mention MPLAB-X. And there are a lot of things that compile without error messages or warnings but fail miserably. A LOT of things.
 
I am working with a PIC18 device and I had the problem of data embedded in the code leaving things off by one byte. I thought that an ALIGN 2 statement after the data would fix it, but alas, no. Had to make an extra byte so the data would align properly. Very clumsy. It would have been nice if the assembler would have given me an error when I made code that was mis-aligned. Or better yet, JUST ALIGN IT! Don't let me make code that is a byte off! Seems like an obvious error to catch, or fix.
 
Another problem that I should have seen coming but where an assembler error message would have saved a lot of debug time: If you have decision/skip and put a call after it, everything goes to hell in the PIC18 because the call is a four byte instruction, so the skip doesn't work correctly:
 
    btfss file,bit
    call vector                ; This does not work! But the assembler is happy to let you get by with it.
 
This is, of course, my fault because the book clearly says that the call is a four byte instruction. But couldn't the assembler catch it and let me know? By the way, when you start trying to debug it and you put a breakpoint on that call, everything goes to pieces.
 
Also, if I access a file that is not in the access RAM and I use the ,a addressing specification, why doesn't the assembler complain? It is an obvious error and very easy to detect. Save me an hour or two of debugging, will ya guys?
 
I have complained about not being able to do   DB   'Hello',0    and they said they will work on it. Defining text messages in code space is really incredibly painful in the PIC-AS world.
 
But the biggest problem (and the most widely hated error message) in PIC-AS is "syntax error". There must be ten thousand things that all generate the same useless "syntax error" message.
 
I still have the problem where one out of three compiles fail because MPLAB-X has left files open so Windows has them marked "in use". I have to stop everything and get the unlocker program up to delete the files before I can compile again. BIG time waster. MPLAB-X is slow enough without having to do this unlock-and-delete game every five minutes.
 
Many people have given advice, and I have tried everything the suggest. Nothing helps.
 
And PLEASE PLEASE fix the BANKMASK problem! What I giant mess that is! If I am passing a file to an opcode that requires only 8 bits of it, just use the lower 8 bits and leave me alone!
 
Anyway, the list of bugs is growing far faster than the releases that fix 'em. I hope somebody is working on it.
 
Topher
 
 
 
 
#16
ric
Super Member
  • Total Posts : 29870
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: XC8 PIC-AS insights 2021/02/02 20:55:07 (permalink)
+2 (2)
ChrisFox
...
Another problem that I should have seen coming but where an assembler error message would have saved a lot of debug time: If you have decision/skip and put a call after it, everything goes to hell in the PIC18 because the call is a four byte instruction, so the skip doesn't work correctly:
 
    btfss file,bit
    call vector                ; This does not work! But the assembler is happy to let you get by with it.

Are you sure?
The instruction is encoded so the second word is a NOP instruction, specifically to make sure that sequence DOES work as intended.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#17
1and0
Access is Denied
  • Total Posts : 12086
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: XC8 PIC-AS insights 2021/02/02 21:24:05 (permalink)
+1 (1)
ChrisFox
Another problem that I should have seen coming but where an assembler error message would have saved a lot of debug time: If you have decision/skip and put a call after it, everything goes to hell in the PIC18 because the call is a four byte instruction, so the skip doesn't work correctly:
 
    btfss file,bit
    call vector                ; This does not work! But the assembler is happy to let you get by with it.
 
This is, of course, my fault because the book clearly says that the call is a four byte instruction. But couldn't the assembler catch it and let me know? By the way, when you start trying to debug it and you put a breakpoint on that call, everything goes to pieces.

Of course that will work.  CALL is a double-word instruction where the second word is a NOP when executed by itself. When the skip it taken, only the first word is skipped.
 
ChrisFox
Also, if I access a file that is not in the access RAM and I use the ,a addressing specification, why doesn't the assembler complain? It is an obvious error and very easy to detect. Save me an hour or two of debugging, will ya guys?

You are programming in assembly, where a LOT of stuffs is YOUR responsibility. It gives you the flexibility to overwrite its default if so desired; that is, when you explicitly specify the Access bit, the assembler assumes you know what you're doing. If you're having troubles keeping up with the Access bit, perhaps you should leave it off and let the assembler automatically inserts the correct Access bit for you.
 
ChrisFox
I have complained about not being able to do   DB   'Hello',0    and they said they will work on it. Defining text messages in code space is really incredibly painful in the PIC-AS world.

Haha, it will probably take them a while to fix it. ;)
 
ChrisFox
And PLEASE PLEASE fix the BANKMASK problem! What I giant mess that is! If I am passing a file to an opcode that requires only 8 bits of it, just use the lower 8 bits and leave me alone!

I couldn't agree with you more!!!
post edited by 1and0 - 2021/02/02 21:37:56
#18
Anobium
Super Member
  • Total Posts : 164
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
Re: XC8 PIC-AS insights 2021/02/02 23:54:04 (permalink)
+1 (1)
ChrisFox
 
I am working with a PIC18 device and I had the problem of data embedded in the code leaving things off by one byte. I thought that an ALIGN 2 statement after the data would fix it, but alas, no. Had to make an extra byte so the data would align properly. Very clumsy. It would have been nice if the assembler would have given me an error when I made code that was mis-aligned. Or better yet, JUST ALIGN IT! Don't let me make code that is a byte off! Seems like an obvious error to catch, or fix.



Is this formally reported  via a Support Ticket? If yes - can you share the ticket number.  I have reported.
#19
Jump to:
© 2021 APG vNext Commercial Version 4.5