Re: GPL+LE/LP pic/pic16 header Interest?

Hey guys,

I saw this discussion on the archives and joined to interject a little
more info about copyright.  I know this has already been discussed, but
I thought I'd contribute some references.

There is a great deal of agreement among the FOSS community that header
files are generally not copyrightable, and the GPL terms don't apply to
them.  This is backed up by RMS and the FSF, which is pretty telling by
itself:

http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

Linus Torvalds agrees:

http://lxnews.org/2011/03/25/android-gpl-problems-totally-bogus/

Both of those cases are with regards to GPL'd works, but there is one
notable court case that generalizes it even more: BayState Technologies,
Inc v. Bentley Systems, Inc. (1996) [no relation to me], district court
found that "technical interfaces... cannot be protected by copyright
law".  The summary also references other related fair use cases,
including Sega Enterprises Ltd. v. Accolade, Inc.  Case summary here:

http://www.fenwick.com/docstore/publications/ip/ip_articles/baystate_holding.pdf

Basically: common public opinion and some lower US court findings hold
that a typical descriptive header file (i.e. no inline functions) is NOT
bound by copyright law.

another 'error 2: Initializer element is not constant' case

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: another 'error 2: Initializer element is not constant' case

Strange :( Same here with sdcc-3.0.0. Should be reported as a bug.

However, it is not severe. You can always remove the type-casting and
successfully compile your code.

Krish

On Tue, Apr 5, 2011 at 9:40 AM, Bob Frankel
<bios.bob.frankel@...> wrote:
> consider the following program, which initializes a static structure
> containing a function-pointer-valued field....
>
> typedef void (*Fxn)();
>
> struct S {
>     Fxn f;
> };
>
> void fxn() {
> }
>
> struct S s = {
>     (Fxn)fxn            /* raises error when compiled with --model-large !!!
> */
> };
>
>
> when i compile this code with --model-medium, everything works fine....  but
> when i compile with --model-large, the initializer causes a compiler
> error....   note also that the problem goes away when the function cast is
> removed!!!   again, everything works just fine in with --model-medium....
>
> any ideas???
>
> thanks in advance
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
>

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

Z80 code size reduction

Dear users of the Z80 port,

I've been working on a new register allocator for some months.

The current protoype already generates better code than current 'normal'
sdcc in most cases. A code size reduction of about 10% seems typical.

A small benchmark can be found at
https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list,
where the rightmost column gives the code sizes for the new allocator.
As you can see, with the new allocator sdcc in most cases generates
smaller code than all other compilers, including the last HITECH-C compiler.

You can download sdcc with the new allocator from
http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz. I have worked on
fixing bugs for about a week; all regression tests complete without
errors, and my own Z80 applications work when compiled with this version.

However it's likely that there are still lots of bugs, thus it needs
testing. Please test this version of sdcc on your code, and tell me
about any problems you encounter.

A short description of the command line options you might want to try:

--optralloc-exact-cost : Use an exact cost function. This should
generate slightly better code than without this option.

--max-allocs-per-node : Higher values result in better code, at the cost
of longer compile time (and higher memory usage during compilation). The
default value is 10000.

--opt-code-size : Optimize for code size instead of speed. Currently has
a relatively small impact on the code generated.

--no-peep : Disables the peephole optimizer. When there's a problem that
goes away when using --no-peep it's most likely a bug in the peephole
optimizer or the peephole rules.

Philipp

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

Re: Z80 code size reduction

On Wed, Apr 6, 2011 at 10:01 AM, Philipp Klaus Krause <pkk@...> wrote:
> Dear users of the Z80 port,
>
> I've been working on a new register allocator for some months.
>
> The current protoype already generates better code than current 'normal'
> sdcc in most cases. A code size reduction of about 10% seems typical.
>
> A small benchmark can be found at
> https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list,
> where the rightmost column gives the code sizes for the new allocator.
> As you can see, with the new allocator sdcc in most cases generates
> smaller code than all other compilers, including the last HITECH-C compiler.
>
> You can download sdcc with the new allocator from
> http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz. I have worked on
> fixing bugs for about a week; all regression tests complete without
> errors, and my own Z80 applications work when compiled with this version.
>
> However it's likely that there are still lots of bugs, thus it needs
> testing. Please test this version of sdcc on your code, and tell me
> about any problems you encounter.
>
> A short description of the command line options you might want to try:
>
> --optralloc-exact-cost : Use an exact cost function. This should
> generate slightly better code than without this option.
>
> --max-allocs-per-node : Higher values result in better code, at the cost
> of longer compile time (and higher memory usage during compilation). The
> default value is 10000.
>
> --opt-code-size : Optimize for code size instead of speed. Currently has
> a relatively small impact on the code generated.
>
> --no-peep : Disables the peephole optimizer. When there's a problem that
> goes away when using --no-peep it's most likely a bug in the peephole
> optimizer or the peephole rules.
>
> Philipp

Looks promising. I'll try to test it against my code sometime this week/weekend.

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

Re: Z80 code size reduction

Am 06.04.2011 17:01, schrieb Philipp Klaus Krause:

> You can download sdcc with the new allocator from
> http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz.

Today's version, with some bugs fixed can be found at:

http://colecovision.eu/stuff/sdcc-or-2011-4-7.tar.gz

Philipp

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

Re: Z80 code size reduction

Another update, with another bug fixed at:

http://colecovision.eu/stuff/sdcc-or-2011-4-8.tar.gz

I have now run out of bugs to fix. This doesn't mean there aren't any
left, but rather that I need your help to find them.

Philipp

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

make CFLAGS error

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: Z80 code size reduction

Philipp Klaus Krause wrote:
> Another update, with another bug fixed at:
>
> http://colecovision.eu/stuff/sdcc-or-2011-4-8.tar.gz
>
> I have now run out of bugs to fix. This doesn't mean there aren't any
> left, but rather that I need your help to find them.
>
> Philipp

I think I may have found one. I'll attach the code. It appears it
doesn't like one of my macros. It works in sdcc (I don't have it in
there, but you can add --opt-code-size and any other options you'd
like to the CC line in src/Makefile) Just FYI, it's
--optralloc-exact-cost that is the breaking option it looks like.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying convention use in e-mail clients?

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Funny 16f687 behavior

I'm trying to get a simple Hello, world LED blinking program
to work, to verify my tool chain and breadboard. Its mostly
working, however it doesn't appear to be honoring the
delays that I'm putting between toggling the LED.

First, the C code:

#ifndef LED_TRIS
#define LED_TRIS  TRISB6
#endif

#ifndef LED_PIN
#define LED_PIN   RB6
#endif

#include "pic16f687.h"

void delay_ms(long ms)
{
    long i;

    while (ms--)
        for (i=0; i < 330; i++)
            ;
}

void main()
{
    LED_TRIS = 0;

    for (;;)
    {
        LED_PIN = 0;
        delay_ms(330);
        LED_PIN = 1;
        delay_ms(330);
    }
}

Here's the first half of the assembly:

...
	global STK02
	global STK01
	global STK00

sharebank udata_ovr 0x0070
...
STK02	res 1
STK01	res 1
STK00	res 1

UDL_helloled_0	udata
r0x1003	res	1
r0x1002	res	1
r0x1001	res	1
r0x1000	res	1
r0x1004	res	1
r0x1005	res	1
r0x1006	res	1
r0x1007	res	1

STARTUP	code 0x0000
	nop
	pagesel __sdcc_gsinit_startup
	goto	__sdcc_gsinit_startup

_main	;Function start
	BANKSEL	_TRISB_bits
	BCF	_TRISB_bits,6
_00117_DS_
;	.line	46; "helloled.c"	LED_PIN = 0;
	BANKSEL	_PORTB_bits
	BCF	_PORTB_bits,6
;	.line	47; "helloled.c"	delay_ms(330);
	MOVLW	0x4a
	MOVWF	STK02
	MOVLW	0x01
	MOVWF	STK01
	MOVLW	0x00
	MOVWF	STK00
	MOVLW	0x00
	CALL	_delay_ms
;	.line	48; "helloled.c"	LED_PIN = 1;
	BANKSEL	_PORTB_bits
	BSF	_PORTB_bits,6
;	.line	49; "helloled.c"	delay_ms(330);
	MOVLW	0x4a
	MOVWF	STK02
	MOVLW	0x01
	MOVWF	STK01
	MOVLW	0x00
	MOVWF	STK00
	MOVLW	0x00
	CALL	_delay_ms
	GOTO	_00117_DS_
	RETURN	
; exit point of _main

The only funny thing I see here is that, while it does a BANKSEL for
the PORT B register (and later for r1000, ...), it doesn't do it for STK0, ...
I suppose this is because they got mapped to 0xFD, ...
while r1000, ... got put at 0xA0, ...

And here's the code for delay_ms:

_delay_ms	;Function start
;	.line	26; "helloled.c"	void delay_ms(long ms)
	BANKSEL	r0x1000
	MOVWF	r0x1000        ; copy argument to r1000, ... - MSB
	MOVF	STK00,W
	MOVWF	r0x1001
	MOVF	STK01,W
	MOVWF	r0x1002
	MOVF	STK02,W
	MOVWF	r0x1003        ; LSB
_00105_DS_
;	.line	30; "helloled.c"	while (ms--)
	BANKSEL	r0x1003
	MOVF	r0x1003,W        ; copy ms since we're doing a post-decrement
	MOVWF	r0x1004
	MOVF	r0x1002,W
	MOVWF	r0x1005
	MOVF	r0x1001,W
	MOVWF	r0x1006
	MOVF	r0x1000,W
	MOVWF	r0x1007
	MOVLW	0xff
	ADDWF	r0x1003,F        ; r1003 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1002,F        ; r1002 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1001,F        ; r1001 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1000,F        ; r1000 += 0xFF
	MOVF	r0x1004,W        ; test old value of ms, W = r1004
	IORWF	r0x1005,W        ; W |= r1005
	IORWF	r0x1006,W        ; W |= r1006
	IORWF	r0x1007,W        ; W |= r1007
	BTFSC	STATUS,2        ; if zero
	GOTO	_00111_DS_        ; jump to return
;	.line	31; "helloled.c"	for (i=0; i < 330; i++)
	MOVLW	0x4a
	MOVWF	r0x1004        ; LSB
	MOVLW	0x01
	MOVWF	r0x1005
	CLRF	r0x1006
	CLRF	r0x1007        ; MSB
_00110_DS_
	MOVLW	0xff
	BANKSEL	r0x1004
	ADDWF	r0x1004,F        ; r1004 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1005,F        ; r1005 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1006,F        ; r1006 += 0xFF
	MOVLW	0xff
	BTFSS	STATUS,0        ; if not carry
	ADDWF	r0x1007,F        ; r1007 += 0xFF
	MOVF	r0x1004,W        ; W = r1004
	IORWF	r0x1005,W        ; W |= r1005
	IORWF	r0x1006,W        ; W |= r1006
	IORWF	r0x1007,W        ; W |= r1007
	BTFSS	STATUS,2        ; if not zero
	GOTO	_00110_DS_        ; inner loop
	GOTO	_00105_DS_        ; outer loop
_00111_DS_
	RETURN	

I don't see anything strange here. The carry stuff took a little while
to accept was correct, since the behavior looked a little like an
issue with going over 8 bits, but I don't see anything wrong.

Any ideas would be appreciated.

Cheers

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev