[z88dk-dev] sdcc_compilation

Bridge to the z88dk-developers mailing list
Post Reply
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

[z88dk-dev] sdcc_compilation

Post by alvin »

No, quite the opposite: The code generator only emits jp (except for a
I must be unknowingly running sdcc’s peephole optimizer on z80asm source. I thought it was switched off. The incompatible syntax is probably getting an incorrect byte count. So that’s another possible problem.


Error at file 'C:\Users\alvin\AppData\Local\Temp\stj8_.asm' line 389: integer '-131' out of range
1 errors occurred during assembly
Errors in source file rand.c:
Error at file 'C:\Users\alvin\AppData\Local\Temp\stj8_.asm' line 389: integer '-131' out of range
^ ---- jr C,l_main00101
Philipp Klaus Krause

Post by Philipp Klaus Krause »

On 03.02.2015 20:15, alvin albrecht wrote:
No, quite the opposite: The code generator only emits jp (except for a
I must be unknowingly running sdcc’s peephole optimizer on z80asm
source. I thought it was switched off. The incompatible syntax is
probably getting an incorrect byte count. So that’s another possible
problem.
--no-peep? But it will cost you, since the peephole optimizations can be
quite useful. But they don't really work with alternative syntax.

Philipp
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

--no-peep? But it will cost you, since the peephole optimizations can be
quite useful. But they don't really work with alternative syntax.
cheers - I only wanted to use the option to make sure the test programs compiled and ran, and they did :) We have 100% source compatibility with sccz80, including the \r\n issue solved (solved in the clib configuration when it is built) and the pragma features on the z88dk side. Choosing one compiler or the other is a simple matter of using "-clib=new" (sccz80), "-clib=sdcc_ix" or "-clib=sdcc_iy" on the command line. This is ideal.

I ran into some build issues last night -- I switched to checking out the repo with svn so I could generate patches, but the build process behaved oddly (some files occasionally disappeared and did not rebuild) so I'll have a go again.

I'm attempting to make changes with minimum impact and the way I will probably do it is introduce a new z80 port that can be selected by invoking sdcc with the name "zsdcc". SDCCmain goes through some process that looks for target via command line option and then invocation name. The PORT structure contains hooks for the peephole optimizer which is how I would get the peeophole to work (a different size estimation function supplied) and a hook for the glue() function which is the final asm-generation step. It turns out most of the functions in SDCCglue are declared static to keep things modular so if I introduce a new glue function, it has to go in that file, which probably no one wants to see. So I've been looking at how to get the right thing to happen out of the existing glue() function. One step is to introduce a new macro !defc that would appear before equates that are emitted. All the asxxx targets would get an empty string assigned to !defc while z80asm would get
"defc". If I change equate outputs to use this macro, that problem would be solved. To shut down the emission of the initialized section I think is easy by zeroing initialized var as first step before glue is called. The changing of names in the intializer section I'm not sure how to wedge in yet. Anyway it can be done and the additional function to peephole size estimation is almost cut and paste of what you've written already. But as you said the least intrusive thing is post-processing with sed or something; we'll have to decide if we want / need access to sdcc internals for z88dk-specific behaviours.



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I think I have sdcc compilation working.

If you run on windows, you can grab an sdcc binary here:
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing

Place that in z88dk/bin or if you are using sdcc already, move your existing sdcc bin out of the way and place this one there. You will also need 'sed' installed which is available with the gnu unix utils for windows.

To compile programs, use z88dk as per usual and make sure the sdcc bin is in your current path.

1. zcc +zx -vn -clib=new test.c -o test

Compile line for sccz80 with the new clib.

2. zcc +zx -vn -clib=sdcc_ix test.c -o test
zcc +zx -vn -clib=sdcc_ix --reserve-regs-iy test.c -o test
zcc +zx -vn -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test

Compile line for using sdcc with the new clib where the clib uses the ix register. Since the clib only uses the ix register, iy is available to sdcc. However on the zx target, iy is also used by the rom interrupt so unless you disable interrupts or use your own isr you will need to add the "--reserve-regs-iy" flag to the compile line so that sdcc will not use iy.

You can control sdcc's optimization level with the --max-allocs-per-node setting (default is 3000)

3. zcc +zx -vn -clib=sdcc_iy test.c -o test
zcc +zx -vn -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test

Compile line for using sdcc with the new clib where the clib uses the iy register. The flag "--reserve-regs-iy" is automatically passed to sdcc. Since sdcc uses ix as frame pointer and the clib uses iy, the c interface functions can be lighter since ix does not have to be saved in library calls.



I do not have the peephole optimizer running yet (it has been disabled) -- that's tomorrow night's project. But I am confident I can get that to work too.

I did not figure out where the peephole optimizer is called and it's late so I've inserted a hack in zcc that takes the sdcc output and passes it through sed to replace all '#' with '+' in the asm source. So that is why sed has to be available at the moment.



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Philipp Klaus Krause

Post by Philipp Klaus Krause »

On 05.02.2015 08:52, alvin (alvin_albrecht@...) wrote:
I think I have sdcc compilation working.

If you run on windows, you can grab an sdcc binary here:
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing

Place that in z88dk/bin or if you are using sdcc already, move your
existing sdcc bin out of the way and place this one there. You will
also need 'sed' installed which is available with the gnu unix utils
for windows.
If you don't mind having a dependency on sed anyway, then IMO,
postprocessing using sed really is the way to go, since

1) There will be no need for maintaining a fork of sdcc
2) You will automatically benefit from sdcc's peephole rules - no need
for separate peephole rules and thus lower maintennace burden here as well.

The postprocessing translater should also be easy in terms of
maintenance burden, since the syntax of the assemblers is unlikely to
change often.

Philipp
User avatar
dom
Well known member
Posts: 2091
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Thu, 5 Feb 2015, Philipp Klaus Krause wrote:
If you don't mind having a dependency on sed anyway, then IMO,
postprocessing using sed really is the way to go, since

1) There will be no need for maintaining a fork of sdcc
2) You will automatically benefit from sdcc's peephole rules - no need
for separate peephole rules and thus lower maintennace burden here as well.

The postprocessing translater should also be easy in terms of
maintenance burden, since the syntax of the assemblers is unlikely to
change often.
I'd prefer not to have the dependency on sed, instead the translation can
be done via the z88dk peephole optimiser (which supports regexes in
anycase) - that way sdcc is vanilla. We're already doing additional
pre-processing, so extra post-processing isn't going to be a problem.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I don't object to text processing as that seems perfectly adequate at the moment. In the event people want the peephole optimization to apply to inlined asm, we'd also have to process the inlined z80 before passing to sdcc. If sdcc is not allowed to look at inlined asm, then it has to be more conservative. Inlined asm should be rare anyway.

For the text processing to work, z80asm needs to be updated to support the "GLOBAL" directive. That is on the docket but it's not implemented yet; that's Paulo's area so that depends on his time.

I think the following text processing will work if anyone would like to try:


**************REMOVE BLOCK OF TEXT FROM EVERY FILE

;--------------------------------------------------------
; ram data
;--------------------------------------------------------
.area _INITIALIZED
{any amount text or until next .area}
;--------------------------------------------------------

replace with commented line of dashes


**************SUBSTITUTIONS (in order)

%s:: -> %s:
%s$ -> l_foo_%s

.area _XSEG -> SECTION IGNORE
.area _STACK -> SECTION IGNORE
.area _CODE_%s -> SECTION code_compiler_bank_%s
.area _CODE -> SECTION code_compiler
.area _DATA -> SECTION bss_compiler
.area _RSEG (ABS) -> SECTION IGNORE
.area _GSINIT -> SECTION code_crt_init
.area _GSFINAL -> SECTION code_crt_exit
.area _HOME -> SECTION IGNORE
.area _CABS (ABS) -> SECTION IGNORE
.area _DABS (ABS) -> SECTION IGNORE
.area _INITIALIZER -> SECTION data_compiler
.area -> SECTION
.ascii -> DEFM
.ds -> DEFS
.db -> DEFB
.dw -> DEFW
#<(%s) -> #(%s & 0xFF)
#>(%s) -> #(%s / 256)
.module -> MODULE
.globl -> GLOBAL
.org -> org
%s = . -> %s:
%s = %s -> defc %s = %s
%s(%s) -> (%s+%s)
__xinit_%s -> %s
# -> +


************** APPEND TEXT TO EVERY FILE

; sdcc implied primitives

EXTERN __divschar
EXTERN __divsint
EXTERN __divslong
EXTERN __divslonglong
EXTERN __divsuchar
EXTERN __divuchar
EXTERN __divuint
EXTERN __divulong
EXTERN __divulonglong
EXTERN __divuschar
EXTERN __modschar
EXTERN __modsint
EXTERN __modslong
EXTERN __modslonglong
EXTERN __modsuchar
EXTERN __moduchar
EXTERN __moduint
EXTERN __modulong
EXTERN __modulonglong
EXTERN __moduschar
EXTERN __mulint
EXTERN __mullong
EXTERN __mullonglong
EXTERN __mulschar
EXTERN __mulsuchar
EXTERN __muluschar
EXTERN __rlslonglong
EXTERN __rlulonglong
EXTERN __rrslonglong
EXTERN __rrulonglong
EXTERN __sdcc_call_hl
EXTERN banked_call
EXTERN banked_ret



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Philipp Klaus Krause

Post by Philipp Klaus Krause »

On 05.02.2015 17:49, alvin (alvin_albrecht@...) wrote:
[?] Inlined asm should be rare
anyway.
And inline asm in need of peephole optimization even more so.

Philipp
stefano
Well known member
Posts: 2151
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

On 05.02.2015 17:49, alvin (alvin_albrecht@...) wrote:
[?] Inlined asm should be rare
anyway.
And inline asm in need of peephole optimization even more so.

Philipp
:)

Probably if I'm writing in pure assembly code I don't want to get it transparently "optimized".



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Philipp Klaus Krause

Post by Philipp Klaus Krause »

On 05.02.2015 21:19, Stefano Bodrato (stefano_bodrato@...) wrote:
On 05.02.2015 17:49, alvin (alvin_albrecht@...) wrote:
[?] Inlined asm should be rare
anyway.
And inline asm in need of peephole optimization even more so.

Philipp
:)

Probably if I'm writing in pure assembly code I don't want to get it transparently "optimized".
But in case you do, sdcc has an option --peep-asm to enable peephole
optimization on inline asm.

Philipp
Post Reply