On 17/02/2015 16:13, "Philipp Klaus Krause" wrote:
>One can still manually run the regression tests for pic16 ("make
>test-pic16" in sdcc/support/regression).
I tried that (after succesfully configure:ing and compiling sdcc 3.4.0)
but somethings not right:
make test-pic16
Running pic16 regress
On 17.02.2015 14:56, Kustaa Nyholm wrote:
> On 17/02/2015 15:43, "Philipp Klaus Krause" wrote:
>>
>> Looks like inline is broken on pic16. Please file a bug report.
>
> Done: #2356 'inline' broken on pic16 port
>
>
>> tested in the nighly regressio tests (which are not done for the pic
>> ports
On 17/02/2015 15:43, "Philipp Klaus Krause" wrote:
>
>Looks like inline is broken on pic16. Please file a bug report.
Done: #2356 'inline' broken on pic16 port
> tested in the nighly regressio tests (which are not done for the pic
>ports).
Why is that, some tests not working? What is the probl
On 17.02.2015 06:31, Kustaa Nyholm wrote:
> On 17/02/2015 06:54, "Kustaa Nyholm" wrote:
>>
>> Ok, gpasm choked (will investigate that later)
>>
>> + gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/testc2asm.o -c
>> ../obj/testc2asm.asm returned errorcode 256
>
> Hmm some quick notes.
>
On 17/02/2015 06:54, "Kustaa Nyholm" wrote:
>
>Ok, gpasm choked (will investigate that later)
>
>+ gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/testc2asm.o -c
>../obj/testc2asm.asm returned errorcode 256
Hmm some quick notes.
Even a short function like
inline int foobar() {
}
Caus
On 17/02/2015 06:35, "Kustaa Nyholm" wrote:
>On 17/02/2015 00:42, "Philipp Klaus Krause" wrote:
>
>>Actually (with some exceptions in std lib functions), sdcc doesn't do
>>anything fancy about inlining at all: we inline exactly the functions
>>declared inline.
>>
>>
>
>Hmmm, I missed that in the
On 17/02/2015 00:42, "Philipp Klaus Krause" wrote:
>Actually (with some exceptions in std lib functions), sdcc doesn't do
>anything fancy about inlining at all: we inline exactly the functions
>declared inline.
>
>
Hmmm, I missed that in the manual, we can actually do inline? Must
try that next
On 16.02.2015 23:20, Alan Cox wrote:
>> Interestingly the code (bar4) that four times expands the whole
>> 'get position' calculation is smaller (585 < 622) than the more
>> conventionally coded subroutine (bar5) based version.
>>
>> And, maybe not surprisingly, it is about four times faster.
>> (
> Interestingly the code (bar4) that four times expands the whole
> 'get position' calculation is smaller (585 < 622) than the more
> conventionally coded subroutine (bar5) based version.
>
> And, maybe not surprisingly, it is about four times faster.
> (The execution times are of course estimate
