Raphael,
thanks for explanation. Would generating symbols instead of sections
including res instructions solve the problem? For example:
_fooEQU0x0040
_barEQU0x0041
instead of
UD_abs_main_40udata_ovr0x0040
_foo
res2
UD_abs_main_41udata_ovr0x0041
_b
OMG. My point of view:
Current wersion PIC16 is OK. We have sfr16 keyword and proper libdev.
In libdev is space allocated for REGL and REGH. Thus for REG too.
In user header files we have declarations:
extern __at(addr) __sfr REGL;
extern __at(addr+1) __sfr REGH;
extern __at(addr) __sfr REG; //3
Hi Borut,
On Sun, 13 Jan 2013 21:34:45 +0100, Borut Ražem
wrote:
> On 13. 01. 2013 19:26, Molnár Károly wrote:
>> On Sun, 13 Jan 2013 17:37:00 +0100
>> Raphael Neider wrote:
>>
>>> We end up with ADRESL and ADRESw
>>> occupying 0xFC3 as well as ADRSH and ADRESw occupying 0xFC4. *Should*
>>> t
On 13. 01. 2013 19:26, Molnár Károly wrote:
> On Sun, 13 Jan 2013 17:37:00 +0100
> Raphael Neider wrote:
>
>> We end up with ADRESL and ADRESw
>> occupying 0xFC3 as well as ADRSH and ADRESw occupying 0xFC4. *Should*
>> the linker allow this?!?
>>
> But, unfortunately, I has just discovered that th
On Sun, 13 Jan 2013 17:37:00 +0100
Raphael Neider wrote:
> Hi,
>
> > This would be good for a new type: __sfr16_t --- "t" -> timer
> >
> > Perhaps even these will: __sfr16_be --- "be" -> big-endian
> > __sfr16_le --- "le" ->
> > little-endian
> >
>
Hi,
> This would be good for a new type: __sfr16_t --- "t" -> timer
>
> Perhaps even these will: __sfr16_be --- "be" -> big-endian
> __sfr16_le --- "le" -> little-endian
>
> Otherwise, I now updated the PIC16 branch (device and include files). From
>
On Sun, 13 Jan 2013 13:23:23 +0100
al_bin wrote:
> W dniu 2013-01-13 09:53:00 użytkownik Molnár Károly
> napisał:
> ...
> > Something left out of the calculation. In the case of TMRx, differ the read
> > and write sequence.
> > write: first TMRxH, second TMRxL
> > read: first TMRxL, second TMR
W dniu 2013-01-13 09:53:00 użytkownik Molnár Károly
napisał:
...
> Something left out of the calculation. In the case of TMRx, differ the read
> and write sequence.
> write: first TMRxH, second TMRxL
> read: first TMRxL, second TMRxH
>
:-)
As for mcs51:
SDCC manual (http://sdcc.sourceforge.ne
On Fri, 11 Jan 2013 08:26:25 +0100
al_bin wrote:
> On 10. 01. 2013 18:09, Raphael Neider wrote:
> ...
> > So code generation is ready (and a lot of things actually just fall
> > into place -- its magic :-D).
> > Did you also already use overlapping SFR definitions (TMR1 and TMR1L above)?
> ...
>
On 10. 01. 2013 18:09, Raphael Neider wrote:
...
> So code generation is ready (and a lot of things actually just fall
> into place -- its magic :-D).
> Did you also already use overlapping SFR definitions (TMR1 and TMR1L above)?
...
As /sdcc/device/non-free/lib/pic14/libdev/* is created in sdcc b
Hi,
>> It does? Well, that would be news to me ... Does it work?!?
>
> Yes, and works fine. As pic14 with patch from my previous post.
> ...
Now, that's cool ... I'll probably uncomment it then. Not sure what
the code transformations (aka optimizations in the backend) make of
it, but one could su
On 10. 01. 2013 18:09, Raphael Neider wrote:
> Hi,
>
>> sfr16 keyword exist for pic16.
>
I> t does? Well, that would be news to me ... Does it work?!?
Yes, and works fine. As pic14 with patch from my previous post.
...
> I agree that this feature would be nice. However, this needs support
> in
On 10. 01. 2013 18:09, Raphael Neider wrote:
> Hi,
>
>> sfr16 keyword exist for pic16.
> It does? Well, that would be news to me ... Does it work?!?
>
>> There is no reason for discard it from pic14 implementation.
> Just lack of time for implementation.
>
>> Together with change duplicate SFR name
Hi,
> sfr16 keyword exist for pic16.
It does? Well, that would be news to me ... Does it work?!?
> There is no reason for discard it from pic14 implementation.
Just lack of time for implementation.
> Together with change duplicate SFR names in non-free include files from ie:
>
> extern __at(0x
14 matches
Mail list logo
