Drew DeVault | 22 Sep 01:37 2014

An update on KnightOS

Hi there! I wanted to let you guys know what us KnightOS folks ended up
doing with SDCC. You might remember my email a few months ago asking
about some of our concerns.

We have decided that the best course of action is to fork SDCC,
considering that we needed fairly radical changes and that they wouldn't
really fit upstream. Since we decided to fork it anyway, we've made our
changes even more radical. So far, we have:

- Dropped support for all but z80
- Switched from autotools to cmake
- Removed unneccessary subsystems such as the simulator
- And cleaned up things in general

Our next steps are to replace sdas/sdld with our own tools, because we
decided that they're a bit too crusty to try and maintain (and our own
assembler is pretty mature anyway). We would also like to refactor out
the C++ code (and with it, the boost requirement), and in a perfect
world we'll make it self hosting.

We hope that we can continue to share code with sdcc upstream, and
ideally take your improvements downstream. It's still GPL'd and such, so
hopefully there won't be much conflict in that area.

And thus, here is "kcc":

https://github.com/KnightOS/kcc

You are of course welcome to take anything you wish from our fork, and
we'd be happy if any SDCC users wanted to come join us in making it better.
(Continue reading)

Hynek Sladky | 10 Sep 16:21 2014
Picon

SDCC and TI-86

Hi,
does anybody use sdcc to build apps for this calculator?
I tried it and but still unsuccessfully. I am looking for example project for sdcc...
I started with this page:
http://www.cemetech.net/forum/viewtopic.php?t=7087&start=0&postdays=0&postorder=asc&highlight=&sid=f1ba1a8256631e31c9ee57e5385d0525
but I don't know what to do next: application can compile, after downloading to calculator it can be run but does nothing - no text output at all... If anybody could send me example application for SDCC I would be grateful.

Thanks.
Hynek Sladky

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Ben Shi | 10 Sep 12:10 2014

About memset/memcpy on stm8

I tried the following c code with command "sdcc a.c -mstm8",

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void ww(void *p, void *q, void *t) {
        memcpy(p, q, 10);
        memset(t, 0, 10);
}
int main(void) {
        char w[10];
        char ww1[10];
        char wq[10];       
        for (;;)
                ww(w, ww1, wq);
        return 0;
}

and got error like
a.c:19: warning 126: unreachable code
?ASlink-Warning-Undefined Global '_memset' referenced by module 'a'
?ASlink-Warning-Undefined Global '_memcpy' referenced by module 'a'

But I did find _memset.rel & _memcpy.rel were archived into stm8.lib, what's wrong ?


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Alan Cox | 9 Sep 00:16 2014
Face
Picon

Dire Z80 output

Is there a good way to get the SDCC compiler to produce decent Z80 output
when handling long types. I'm getting some really long and quite
revolting code out of sdcc whenever I have longs involved

Stuff like

	ld	-4 (ix),l
	ld	-3 (ix),h
	ld	-2 (ix),c
	ld	-1 (ix),b
	pop	af
	ld	a,#0x10
00115$:
	sla	-4 (ix)
	rl	-3 (ix)
	rl	-2 (ix)
	rl	-1 (ix)
	dec	a
	jr	NZ,00115$

	(and then goes on and loads them into registers...!)

Rather than generating

00115$:	sla	l
	rl	h
	rl	c
	rl	b
	dec	a
	jr nz, 00115$

Initializers like

;devsd.c:134: sd_first_uzi_sector = 0;
	xor	a, a
	ld	(#_sd_first_uzi_sector + 0),a
	ld	(#_sd_first_uzi_sector + 1),a
	ld	(#_sd_first_uzi_sector + 2),a
	ld	(#_sd_first_uzi_sector + 3),a
;devsd.c:135: sd_blockdev_count = 0;
	ld	hl,#_sd_blockdev_count + 0
	ld	(hl), #0x00
	ld	hl,#_sd_blockdev_count + 1
	ld	(hl), #0x00

rather than
	xor	a
	ld	hl, #_sd_first_uzi_sector
	ld	(hl), a
	inc 	hl
	ld 	(hl), a
	...
	ld	hl, #_sd_blockdev_count
	ld	(hl), a
	inc	hl
	ld	(hl), a

and also weirdness like

	ld	-1 (ix),d
	ld	-2 (ix),e
	ld	-3 (ix),h
	ld	-4 (ix), l
	ld	-4 (ix), l
	ld	a,-3 (ix)
	ld	-3 (ix),a

at which point I'm in the 'stare in disbelief' state.

Some of it works better being split into tiny functions but then the
function call overhead (passing 32bit values by pointer, lack of argument
passing in registers for simple arguments) produce call/entry/exit
overhead thats as bad as the first case.

Currently using sdcc 3.3.0 and -mz80 --opt-code-size --max-allocs-per-node
5000 --Werror --stack-auto

The integer and pointer code is in most cases quite respectable (except
for the poor function calling API) it's just "long" that seems to make
the compilers brains fall out.

Using max-allocs-per-node=10000 fixes some but introduces other bizarre
bits out output like

	push 	hl
	push 	hl
	pop	hl
	pop	iy
	
and takes ages to run.

It's also noticable the compiler seems to like to generate weirdness like

	pop	af
	ld	hl, something
	push	hl
	[reloads hl with something different before reuse]

not the expected

	ld	hl, something
	ex	(sp), hl

which is 2 clocks faster and 1 byte shorter, and even more efficient when
the return value is in HL and being used as the argument.

Alan

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
remi | 5 Sep 20:34 2014
Picon

stm8 sdas : variable problem

Hello

SDCC : stm8 3.4.1 #9068 (Sep  5 2014) (Linux)

I dont see the difference between this :

I have _lcdchar   declared by : which seems not working, at least the 
way variables
   are to mee in assembly ...

	.area OSEG
_varOne:
	.ds	1
_lcdchar:
	.db	1

	.area CSEG

.
.which seems not working, at least the way variables
   are to mee in assembly ...
.

A)

;try write I                          ### this block doesnt work: prints 
trash

	ldw	x, #0d05
	call	delay_m

	mov	_lcdchar, #0b01001001

	ld	a,_lcdchar	; "I" upper "i" : ascii code in the hd44780
	and	a,#0b11110000	; delete lower nib
	or	a,#0b00000011	; put in that : data write + bkl ON
	ld	PD_ODR, a	; #0b01000011
	bset	PD_ODR, #3
	bres	PD_ODR, #3
	ldw	x, #0d5
	call	delay_m
	ld	a,_lcdchar	; "I" upper "i" : ascii code in the hd44780
	swap	a
	and	a,#0b11110000	; delete lower nib
	or	a,#0b00000011	; put in that : data write + bkl ON
	ld	PD_ODR, a
	bset	PD_ODR, #3
	bres	PD_ODR, #3

And that:

B)
;try write I                        ### this block writes a capital i .

	ldw	x, #0d05
	call	delay_m

	ld	a,#0b01001001	; "I" upper "i" : ascii code in the hd44780
	and	a,#0b11110000	; delete lower nib
	or	a,#0b00000011	; put in that : data write + bkl ON
	ld	PD_ODR, a	; #0b01000011
	bset	PD_ODR, #3
	bres	PD_ODR, #3
	ldw	x, #0d5
	call	delay_m
	ld	a,#0b01001001	; "I" upper "i" : ascii code in the hd44780
	swap	a
	and	a,#0b11110000	; delete lower nib
	or	a,#0b00000011	; put in that : data write + bkl ON
	ld	PD_ODR, a
	bset	PD_ODR, #3
	bres	PD_ODR, #3

thnx again for stm8 support ! :)

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
remi | 5 Sep 23:23 2014
Picon

stm8 sdas : variable problem

Hello

SDCC : stm8 3.4.1 #9068 (Sep  5 2014) (Linux)

I dont see the difference between this ( A and B ) :

I have _lcdchar   declared by :

.area OSEG
_varOne:
.ds	1
_lcdchar:
.db	1

.area CSEG

.
.which seems not working, at least the way variables
   are to mee in assembly ...
.

A)

;try write I                          ### this block doesnt work: prints 
"trash"

ldw	x, #0d05
call	delay_m

mov	_lcdchar, #0b01001001

ld	a,_lcdchar	; "I" upper "i" : ascii code in the hd44780
and	a,#0b11110000	; delete lower nib
or	a,#0b00000011	; put in that : data write + bkl ON
ld	PD_ODR, a	; #0b01000011
bset	PD_ODR, #3
bres	PD_ODR, #3
ldw	x, #0d5
call	delay_m
ld	a,_lcdchar	; "I" upper "i" : ascii code in the hd44780
swap	a
and	a,#0b11110000	; delete lower nib
or	a,#0b00000011	; put in that : data write + bkl ON
ld	PD_ODR, a
bset	PD_ODR, #3
bres	PD_ODR, #3

And that:

B)
;try write I                        ### this block writes a capital i .

ldw	x, #0d05
call	delay_m

ld	a,#0b01001001	; "I" upper "i" : ascii code in the hd44780
and	a,#0b11110000	; delete lower nib
or	a,#0b00000011	; put in that : data write + bkl ON
ld	PD_ODR, a	; #0b01000011
bset	PD_ODR, #3
bres	PD_ODR, #3
ldw	x, #0d5
call	delay_m
ld	a,#0b01001001	; "I" upper "i" : ascii code in the hd44780
swap	a
and	a,#0b11110000	; delete lower nib
or	a,#0b00000011	; put in that : data write + bkl ON
ld	PD_ODR, a
bset	PD_ODR, #3
bres	PD_ODR, #3

thnx again for stm8 support ! :)

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Drew DeVault | 30 Jul 04:16 2014

Supporting an odd ABI for a kernel that wasn't designed for C

Hi there! I am Drew DeVault, the primary maintainer of KnightOS:

https://github.com/KnightOS/kernel

It's a z80 operating system that runs on TI calculators. Currently, both
the kernel and userspace are written entirely in assembly. We would like
to provide support for C in userspace for the upcoming release of kernel
0.7.0, and we would like to use SDCC for this purpose. However, we have
some difficulty.

KnightOS relocates programs at runtime as they are executing, by means
of these macros:

	kcall(addr)		; RST 0x08 \ CALL addr
	kjp(addr)		; RST 0x08 \ JP addr
	kld(register, addr)	; RST 0x08 \ LD register, addr

The restart at 0x08 relocates these by modifying the code to read as such:

	NOP \ CALL absolute_address
	NOP \ JP absolute_address
	NOP \ LD register, absolute_address

Also supported is kjp(cc, addr) and kcall(cc, addr). Of course, this
only affects references that live inside the running executable.

The ideal solution to this problem would be for SDCC to be aware of this
paradigm and to directly emit compliant assembly. Since SDCC cannot
currently do that (or at least we don't think it can), we are
considering some alternative options. The one we currently have in mind
is processing the assembly source before the assembler gets to it, but
this has the potential issue of screwing up relative jumps (which can
only jump a maximum of 127 bytes in either direction). Manipulating
assembly source like this is also just a crappy solution in general, so
we'd like to find something else.

Do you folks know of a good way we can solve this problem? Is this
something SDCC could be extended to support, or are we better off
figuring out an external solution?

On another note, we also have an ABI that is primarily designed for
assembly users. This means that it assumes the caller is responsible for
managing registers how they please and expects the caller to load
arguments into specific registers that vary depending on the syscall
being made. See the reference documentation for details:

http://www.knightos.org/documentation/reference/system.html

We can work around this problem by writing verbose C shims around our
syscalls, like so:

inline void fast_copy(SCREEN *screen) __naked {
	__asm
	PUSH IY
	INC SP
	INC SP
	POP IY
	PUSH IY
	CALL FASTCOPY ; Expects IY to be pointer to display memory
	DEC SP
	DEC SP
	POP IY
	__endasm;
	screen; /* Squelch warning */
}

Is there a more appropriate mechanism for doing this? Ideally we could
mention to the __asm directive which registers we plan on clobbering and
SDCC would figure out the ideal way to work this into the surrounding
code. Please note that we may not be able to use the new __asm(...)
format, because we need to preprocess it to resolve FASTCOPY.

One last question: with compilers like gcc, the target can be specified
at configure time, which will set up good defaults for target
architecture and a crt0 and ABI considerations and such. Can we do
something similar with SDCC to avoid asking users to write long
incantations into their makefiles?

Thanks for reading my long email, I appreciate it!

--
Drew DeVault

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
Joshua Lansford | 18 Jul 15:08 2014

uIP ported to PICDEM.net 2

Hey guys,
  I just got uIP .9 is working on MIcroChip's PICDEM.net 2 board being compiled by sdcc.  :-) The PICDEM.net 2 board uses the PIC18F9797J60 with an internal PHY.   Microchip's driver files are of course non-free but can be distributed as for a MicroChip uP or Ethernet controller.  No changes had to be made to uIP .9 code.
Hope this wasn't effort duplication... :-P
The uIP example program currently connected in is the one which responds with "ok" to any messages sent in on a TCP connection on port 1234.
~Joshua
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Ben Shi | 11 Jul 10:48 2014

Build SDCC on ARMv7

Hello,

I built SDCC (with only the STM8 port enabled) and did regression test on an ARMv7 machine, and the build procedure cost 40 minutes, the only stm8 regression test cost 3 hours.

Is there anybody has ever tried the same work, and how to improve the performance ? Or suggest a faster board to me.

My board is CubieBoard v2, http://cubieboard.com, with a Debian Wheezy installed.

1 GHz dual-core Cortex-a7
1 GB DDR3 RAM

Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14)

Ben
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Daniel Michalik | 10 Jul 11:24 2014
Picon

compiling 9043: right-hand operand of comma expression has no effect

Dear all,
I cannot compile the current version of sdcc. Problem seems identical to
what is described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746906

| make
| [...]
| In file included from opncls.c:26:0:
| opncls.c: In function ‘bfd_fopen’:
| bfd.h:529:65: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
|  #define bfd_set_cacheable(abfd,bool) (((abfd)->cacheable = bool), TRUE)
|                                                                  ^
| opncls.c:261:5: note: in expansion of macro ‘bfd_set_cacheable’
|      bfd_set_cacheable (nbfd, TRUE);
|      ^
| cc1: all warnings being treated as errors

| $ gcc --version
| gcc (Debian 4.9.0-7) 4.9.0

I can of course disable the error on warnings, but maybe this should be fixed
in the repository? 

Kind regards,
Daniel

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Sdcc-user mailing list
Sdcc-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Joshua Lansford | 9 Jul 13:39 2014

Re: pic18

On Tue, Jul 8, 2014 at 4:03 PM, Unix Savvy Brian <bwitt <at> value.net> wrote:
Please provide some output with the error message you are getting.  You might want to add -v option to show the intermediate steps actually taken by the SDCC front-end.
 
that would be helpful.


Here is the command and the output of sdcc when compiling for the PIC.

====
user <at> enj:~/sdcc/proj/count$ ls
count.c
user <at> enj:~/sdcc/proj/count$ cat count.c
//#define __16f877
#include"pic16/pic18f97j60.h"

//word at 0x2007  __CONFIG = 0x3f72;

unsigned char count;

#pragma config XINST=OFF

void main(void) {

        TRISJ = 0;
        count = 0;
        while(1) {
                PORTJ = count;
                count ++;
        }

}
user <at> enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free -p18f97j60 count.c
message: Using default linker script "/usr/local/share/gputils/lkr/18f97j60_g.lkr".
user <at> enj:~/sdcc/proj/count$ ls
count.asm  count.c  count.cod  count.hex  count.lst  count.o
user <at> enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free -p18f97j60 count.c -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.4.1 #9036 (Jul  7 2014) (Linux)
published under GNU General Public License (GPL)
user <at> enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free -p18f97j60 count.c --verbose
Processor: 18f97j60
sdcc: Calling preprocessor...
sdcc: Generating code...
sdcc: Calling assembler...
sdcc: Calling linker...
message: Using default linker script "/usr/local/share/gputils/lkr/18f97j60_g.lkr".
===
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Gmane