Hi Kusti,
I would have to look into extended instructions again.
I think the problem is that some of the design decisions taken by the PIC16
port (like placing local variables into the access bank) are directly
affected by the modified semantics of access to memory via the access bank
bank (0x00-0x5F at least, which is now relative to FSR2 instead of directly
mapping to 0x00..0x5F). We could try to force FSR2 to 0x0000 at virtually
all times where the access bank is accessed -- but again that's something I
would have to look into. FSR2 is currently used as frame pointer. Removing
the frame pointer, making everything relative to the stack pointer, and
forcing FSR2 to 0x0000 (never touch it) is probably the way to go for now.
I'll try to give it a shot this weekend. If you are willing to help in
testing (at least reporting what does not/no longer work once the changes
are made ;-)), we should be able to find a solution here.
Hoping to report back soon,
Raphael
2015-01-29 21:09 GMT+01:00 Kustaa Nyholm <kustaa.nyh...@planmeca.com>:
> Hi,
>
> I'm at cross roads, should I go on with SDCC (which I'm happy
> with and familiar) or move to MPLAB X compilers...
>
> The dilemma:
>
> I'm planning to use the Diolan bootloader which uses extended
> instructions set. That bootloader is very nice as it is in
> asm and fits (just!) into the boot block and offers encryption
> for the firmware to be bootloaded.
>
> Problem is that code compiled with SDCC does not work with
> the extended instruction set enabled and as this [extended
> instruction set mode] cannot be changed at run time this
> combination [SDCC and diolan] does not work.
>
> I converted the diolan bootloader to 'legacy' mode, but
> of course it did not fit. So I've optimised it and now it
> fits and runs, but the encryption does not work properly,
> obviously some of optimisations or conversion broke something.
>
> I'm working on fixing that but the big question is, if I
> would be better of with MPLABX compilers in the long run...
>
> In theory the MPLABX compiler with the extended instruction
> set enabled should produce better and faster code so in
> that respect the answer is obvious ... why go through all
> the trouble making the diolan work with SDCC... OTH
> emigrating to a new compiler is bound incur some pain and
> a learning curve. Also my own USB stack optimised for SDCC
> is half size of the (Free) USB M-stack (not to mention
> Microchip's own stack) ... at least when compiled with
> the free MLABX C-compiler.
>
> As this is a free as beer project I don't feel like paying
> for the compiler ... though I could afford it.
>
> So any on going work on SDCC to support extended instruction
> set?
>
> I could live with code generation that does not take advantage
> of the extended instruction set as long as the generated code
> would be compatible with it.
>
> This document (at the end) mentions that it is possible to
> write code like that with some 'hacks'
>
> diolan plus readme.zip
> <
> http://dangerousprototypes.com/forum/download/file.php?id=5934&sid=783f188
> 28453f727272fbda73537545d>
>
> I'm not familiar with SDCC code generation or PIC assembly
> so I can't evaluate if it would realistic to do something like
> that.
>
> cheers Kusti
>
>
>
>
>
> This e-mail may contain confidential or privileged information. If you are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden. We will not be liable for direct, indirect, special or
> consequential damages arising from alteration of the contents of this
> message by a third party or as a result of any virus being passed on or as
> of transmission of this e-mail in general.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
