gnupic: Thread: What are stkadj and FUSTART???

I found these 'pseudo-instructions' in the C18 lib sources, but no
mention of them anywhere... if these are macro I can't find them.

Are these some kind of undocumented extensions of mpasm? Probably they
are for computing stack usage but maybe they actually *emit* some
code...

Do you have any info on these?


-- 
Lorenzo Marcantonio
Logos Srl

hey ! 

cool dude you speak plutonian , im green 

so wtf--- what in the future 


im trying to get my gnuu project going thees dAys.solar radio canon 



any idea ..


eot 

On Tue, Mar 13, 2012 at 10:08:22AM -0600, Joe Pfeiffer wrote:
> Spent a while looking around, and found mention of them elsewhere...
> but couldn't find them in the gpasm source at all.

I asked because gpasm chokes on them... mpasm probably has them implemented for
some COFF stuff... indeed I found a thread around where someone had to rename
his function called stkadj!

Microchip during its "innovation" removed a way to set the include path in mpasmx (and the errors are in an .err file only, no stderr logging!)

Funny thing: mpasmx seems to be written in... pascal! (object free pascal, probably, the exec is not stripped so the inner symbols are visible:P)

A 'strings' check on mplabx revealed these between the various opcodes:

ICD_IRQ      
ICD_POP      
ICD_PUSH     
ICD_RET      
EMULDIS
EMULEN
FUEND
FUSTART
MOVFX
RELOCTLMERGE
SCNEND_LFSR  
SCNSTART_LFSR
STKADJ
TRAP
TRET

Some of these are mentioned here:

http://support2.microchip.com/KBSearch/KB_Ticket.aspx?ID=Tt6UJ9A0003LM

so it seems there are undocumented features in mpasm

> This link includes a stkadj function, but I don't know if it's the
> same stkadj you're finding (it's being used in some table lookup code)

No, it's some kind of internal macro, the comment says 'pseudo-instruction'
I think its used for critical stack depth analysis (mplink has a -g flag to "generate the report file for stack analysis", but didn't found any doc)

> And here's a use of FUSTART -- I've got *no* idea what it's being used
> for (from context, I wouldn't be surprised if you came back and told
> me that this is the code you found it in!)

More or less... C18 libc, still; IMHO is a marker to emit a COFF function
something (there's also FUEND).

Morale: removed them, code works XD

-- 
Lorenzo Marcantonio
Logos Srl

2012/3/13 Lorenzo Marcantonio ####@####.####
> Funny thing: mpasmx seems to be written in... pascal! (object free pascal, probably, the exec is not stripped so the inner symbols are visible:P)

Yes, I've seen it mentioned elsewhere. I've understood it is somewhat
of a burden to Microchip because not many people are competent in
maintaining anything written in pascal.

> A 'strings' check on mplabx revealed these between the various opcodes:
>
> ICD_IRQ
> ICD_POP
> ICD_PUSH
> ICD_RET
> EMULDIS
> EMULEN
> FUEND
> FUSTART
> MOVFX
> RELOCTLMERGE
> SCNEND_LFSR
> SCNSTART_LFSR
> STKADJ
> TRAP
> TRET
>
> Some of these are mentioned here:
>
> http://support2.microchip.com/KBSearch/KB_Ticket.aspx?ID=Tt6UJ9A0003LM
> so it seems there are undocumented features in mpasm

Yes, the SCNSTART_SFSR and END have relocations in the object file and
linker modifies the section information into it. However these
relocations are not implemented in the gputils linker.

When using ICD, MPLAB adds some code for the debugger. Some of these
sound like they could be used in that code to access some debugging
features of PICs that are not public to us mortals.

>> This link includes a stkadj function, but I don't know if it's the
>> same stkadj you're finding (it's being used in some table lookup code)
>
> No, it's some kind of internal macro, the comment says 'pseudo-instruction'
> I think its used for critical stack depth analysis (mplink has a -g flag to "generate the report file for stack analysis", but didn't found any doc)

C18 generates some extra information into the COFF file that you can
not generate with MPASM. Part of it is the call tree that is used by
the linker mainly to allocate overlay storage class function local
variables ("activation records"). I have not tried this -g option, but
it most likely uses this information for a report.

>> And here's a use of FUSTART -- I've got *no* idea what it's being used
>> for (from context, I wouldn't be surprised if you came back and told
>> me that this is the code you found it in!)
>
> More or less... C18 libc, still; IMHO is a marker to emit a COFF function
> something (there's also FUEND).
>
> Morale: removed them, code works XD
>
> --
> Lorenzo Marcantonio
> Logos Srl
>

On Wed, Mar 14, 2012 at 08:57:00AM +0200, Marko Kohtala wrote:
> Yes, I've seen it mentioned elsewhere. I've understood it is somewhat
> of a burden to Microchip because not many people are competent in
> maintaining anything written in pascal.

I don't see a lot of competency required... pascal is more or less like
C and (at least in Borland) the object system was quite simple... it's
more like "you usually don't program in pascal because people already
know C" :P

> When using ICD, MPLAB adds some code for the debugger. Some of these
> sound like they could be used in that code to access some debugging
> features of PICs that are not public to us mortals.

The 'debugger executive' also has to be assembled in some way, I doubt
that MC hand coded it in hex!

> variables ("activation records"). I have not tried this -g option, but
> it most likely uses this information for a report.

It's some kind of raw report more or less resembling the call tree.
Probably its used behind the scene for that. Funny thing is the option
is documented but the file format or usage is not.

Anyway I opened a ticket asking for explanation, maybe these would be
useful to implement.


-- 
Lorenzo Marcantonio
Logos Srl

On Wed, Mar 14, 2012 at 08:37:38AM +0100, Lorenzo Marcantonio wrote:
> Anyway I opened a ticket asking for explanation, maybe these would be
> useful to implement.

Got a response for microchip support. These directive are comment only and, as I tought, are used by a 3rd party stack analysis product.

These are officially undocumented and can be ignored.

I think that at least gpasm could ignore them instead of choking on them (something like #define ing them to blanks...)

-- 
Lorenzo Marcantonio
Logos Srl