Molnár Károly | 27 Sep 11:19 2014
Picon

The gputils-1.4.0_RC1 released

		Dear sdcc users!

The gputils-1.4.0_RC1 has been released. The source code package is available at
http://sourceforge.net/projects/gputils/files/gputils/1.4.0/gputils-1.4.0_RC1.tar.gz
Windows 32bit setup package is at
http://sourceforge.net/projects/gputils/files/gputils-win32/1.4.0/gputils-1.4.0_RC1.exe

The gputils 1.4.0_RC1 includes the following enhancements:

-- Extended error and warning messages.
-- Enabled the CONFIG directive on the 12-bit and 14-bit devices.
-- Enabled the IDLOCS directive on the pic18fxxx devices.
-- The gpasm lists the properties of the processors.
-- New predefined constants in the gpasm: __EEPROM_START, etc.
-- The gpdasm shows the names of SFRs and bits, in addition shows the labels in code.
-- The inc and lkr files are synced with MPLABX 2.20 version.

More details:
https://sourceforge.net/p/gputils/blog/2014/06/the-major-changes-since-the-stable-release-2/

Molnár Károly

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Alan Cox | 25 Sep 21:13 2014
Face
Picon

Sane way to put C functions into a different section

Is there a "proper" way to put some functions in a file into a different
section for linking

Right now I'm doing

/* Force the rest of this code into common */

void dummy(void) __naked
{
__asm
  .area _COMMONMEM
__endasm;
}

which while bletcherous does seem to work, at least for my use case.

I've also got another ugly I'm having to use because sdcc errors

#ifdef SOMETHING
<entire code>
#endif

which produces an error that ANSI C doesn't permit an empty file. While
that is correct I see nothing in the standard that says "after
preprocessing" and would submit that is a compiler bug ?

Alan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
(Continue reading)

remi | 25 Sep 19:11 2014
Picon

full assembly help

Hello

I have spent a few years with MChip, I switched to stm8 recently.

One of the reasons is pointer handeling (pic16 and 18) very limited ...

and now, I am almost learning two things in the same time, STM8 and 
sdasm .

Can some one direct me a little on how pointers are beeing

used in  sdasstm8 ?

in this snipet, i am trying to go trhu a string and print it ...

no luck so far, only the "t" is printed .

I have already went thru sdccman.pdf ... but it mostly talk about its C 
and inline assembly ,

and stm8 axemples elsewhere are for other assemblers ... :)

my goal , is to write 100% assembly code .

Best regards

.area DATA
_varOne:
.ds 1
_lcdchar:
(Continue reading)

Stijn Souffriau | 25 Sep 13:40 2014

Inline assembly with parameters

Hi all,

 

I have a question regarding inline assembly in sdcc:

 

I have some assembly code which I would like to put in a macro that is to be called many times throughout my C-code. For efficiency reasons this short piece of assembly must be inlined hence I can’t use a function. Also this macro must take an argument and herein lies the problem. My assembly code must know which register contains this input value, i.e. I need a way to “connect” my C variables to my assembly registers.

 

I need something like:

 

// placeholder == ‘%r’, to be substituted by whatever register the compiler allocates for ‘val’

#define MY_MACRO (val) __asm__(“mov a,%r”, val)

 

Is something like this possible?

 

Even better would be if the compiler could also substitute a placeholder by a free register that is unused by the surrounding function for more complicated computations:

 

// placeholder == ‘%ur’, register to be reserved and substituted

#define MY_MACRO (val) __asm__(

      “mov %ur,a\n”,

      “dec %ur\n”,

      “mov a,%ur\n”

)

 

Thanks,

 

Stijn

 

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
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.

--
Drew DeVault

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
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

Gmane