Le lundi 16 novembre 2009, Gordon Henderson a écrit :
> It's doing a mighty fine job on my project.
In mine too... In the earlier setps of my project I had first started
converting some fast interrupt code into asm, expecting more compact and
performing code, but I soon realized that there was l
> Glad I wasn't put-off by what
> I found online - which seems to be many years old now, saying it's still
> unstable, not suitable, etc., etc., etc. ...
Yeah,
its a pitty that this sort stigma stays, we should do better job in
adverticing SDCC as very usable Free compiler it is!
So for posteri
On Mon, 16 Nov 2009, Michel Bouissou wrote:
> Hi Gordon,
>
>> Saw this posting recently which made me think... Especially as I'm doing a
>> lot of floating pint work which would no-doubt be accellerated by the
>> hardware multiply, however I've just had a look at some of the code in my
>> project.
Hi Gordon,
> Saw this posting recently which made me think... Especially as I'm doing a
> lot of floating pint work which would no-doubt be accellerated by the
> hardware multiply, however I've just had a look at some of the code in my
> project... Although it has that warning, it is using the MUL
On Tue, 10 Nov 2009, Michel Bouissou wrote:
> Hi there,
>
> Well, I've finally converted my PIC16 project to PIC18, and I was taking a
> look
> at the first SDCC .asm output that accepted to compile OK.
>
> My attention was drawn by the following SDCC-generated comment in the .asm
> file
> :
>
>
Hi there,
Well, I've finally converted my PIC16 project to PIC18, and I was taking a look
at the first SDCC .asm output that accepted to compile OK.
My attention was drawn by the following SDCC-generated comment in the .asm file
:
; ;multiply lit val:0x02 by variable _resetSource and store in
