Re: [Sdcc-user] Could SDCC support the Zilog Z380 with 32bit addressing?
On Sat, 31 May 2014 13:38:55 +0200 Ardillas del Monte wrote: > Hi, > > I'm trying to find some way of compiling C code for the Z380, with 32bit > linear addressing. The Z380 is compatible with the Z80, so any Z80 compiler > could be a good start point. I think not. The Z80 is a horrible processor for C because it lacks proper stack relative addressing modes. Z380 has stack pointer relative addressing. It also has a lot of register banks. It may be able to run Z80 code but its 'native' instruction set needs a very different compiler. The simple fact you can do things like LD HL, (SP-30) totally changes the way you generate code IMHO. > But I was wondering whether SDCC has indeed some imposed design limitation > for not allowing 32bit pointers, or if there's no such limitation. SDCC has 24/32bit pointers on some things, at least for some far types. > In other words, could the Z80 backend support 32bit pointers for full Z380 > support, or would that be an incompatible task with the SDCC design and > concept? You would I think want to treat it as a completely new compiler target - different timings, different registers, different sizes, different instruction set. That'll be true whatever compiler you use. Might be easier to knock something up with one of the other compilers if you don't need good quality code. Probably even cheaper still to use a less zany processor 8) If you are willing to go with a commercial solution then Zilog produced "380-C" which ran under Windows. Alan -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Could SDCC support the Zilog Z380 with 32bit addressing?
> I disagree. sdcc supports targets that might be called horrible for C. > But the Z80 is not one of them. The Z80 is okay; not pefect, but okay. > It is not too hard to set up a frame pointer (as sdcc usually does in > ix), and use it for accessing the stack. I guess its all relative, but if you compare native assembler to compiler performance then Z80 does not run C that well compared to many processors with better stack relative operations. It's great at COBOL but not C. 8bit at a time IX relative operations with very long cycle times may work, but the performance versus non stack argument languages is awful. Yes there are CPU's a lot worse at running C and SDCC does minor miracles. > > The simple fact you can do things like LD HL, (SP-30) totally > > changes the way you generate code IMHO. > > Not really. You save the code for setting up the frame pointer at > function entry, but otherwise the generated code is very similar. sdcc > has backends for the Rabbit 2000, Rabbit 3000A and TLCS-90. These do > have some instructions with stack-pointer-relative adressing, but in > the sdcc source the backend is the same as the Z80 one (with a few > if(TARGET_IS_TLCS90), etc) in there. You also need to allocate stuff carefully to the various register banks and the stack but I bow to your far superior knowledge of SDCC Alan -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] 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=1 fixes some but introduces other bizarre bits out output like pushhl pushhl 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 pushhl [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 ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Dire Z80 output
> When I have the tie and memory, I sometimes go up to > --max-allocs-per-node 1000. However, long and long long have not > been the focus of optimization. So far they seemed relatively rare. And > optimizations tend to focus on the common case. I gave it a spin at 100 max allocs per node and it took about two hours to build. It did come out another 2.5K shorter which is pretty impressive (down from 34K to 31.5K). Might even fit into 2 16K ROM banks like that, assuming I can find an efficient split. Not tried booting it yet though ;-) The resulting asm for long types seems to be a fair bit better but it's still making a couple of repeated bizarre choices. In particular _sd_init_start:: _sd_init: ;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 is still there (not using inc hl or the fact a is known to be 0 much of the rest of the code size looks now to be limited just by the lack of call with arguments in registers > > It's also noticable the compiler seems to like to generate weirdness like > > > > pop af > > ld hl, something > > pushhl > > [reloads hl with something different before reuse] > > > > not the expected > > > > ld hl, something > > ex (sp), hl > > Can You give a short compileable example to reproduce this? I will try - it's the usual story, the obvious test case works fine 8) 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 ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] 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
#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
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Sane way to put C functions into a different section
On Thu, 25 Sep 2014 23:29:03 +0200
Philipp Klaus Krause wrote:
> On 25.09.2014 21:13, Alan Cox wrote:
> > 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.
>
>
> Why can't you put those functions that need to go to different sections
> into different files? That should make things easier.
Because
- its two pieces of code that need to be modified together so splitting
them up is going to result in hard to find bugs when they get out of
sync
- it would mean making a lot of static variables global
In the gcc world I can do this and it's quite useful. I can however fold
the sdcc hack into a macro and hide it if need be thanks to sdcc having a
decent C preprocessor.
Alan
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] STM8 ascii / extended ascii
> it doesnt work, because the essemblers (maybe not all?) do not map it > thru the Extended ascii table, meaning cant find it in the standard > ascii Which extended ASCII, there are hundreds of extended ASCII variants ? > So my question, is , is it worthy to make the assembler ; extended-ascii > aware ? that all :) To cover Chinese you would need unicode (and indeed to cover just about any language properly). However that's not fun in 8bits and presupposes your output is unicode aware. Mapping tables would be useful - but you would have to specify which 'ascii' you were using so the tools knew how to translate from unicode into your local target. (cc65 does this for 'Petscii' because Commodore boxes don't actually use ASCII most of the time). Alan -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Changing the default for char from signed char to unsigned char
> > The C standard states that char should be either signed char or unsigned > > char. > > The only concern I have is backward-compability. I mean if someone's > program relies the default sign char, will this change breaks his code? >From a standards perspective the code was already broken. But yes - it would. A lot of 8bit processors are much better at unsigned char (and 16bit ones too) so I'm for the change. I already have to cover unsigned default char on non Z80 platforms. Alan -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80: function in RAM
> BTW, it seems to me that there is some problem with crt0.s - I have to > have my own start-up routine so I used crt0.s as template. Unfortunately > it can't be compiled unless .globl is added for l__INITIALIZE* and > s__INITIALIZE* values. Does it work differently when using standard crt0.s? Not really. You want to do two things in the start of crt0.s 1. Mention all the sections you have in the order you want them to be linked (in particular gs* ordering matters a lot) 2. .globl any s__ or l__ symbol you need to reference in the crt0.s code itself. What I do for Fuzix btw is I have a program that loads the binary image built from sdcc and then copies the INITIALIZER data into INITIALIZED, trims the image and resave it. As I link INITIALIZER somewhere bogus (or at the end of the image) I can then trim the image to size. I can send you the source for that tool - it's pretty trivial as it just reads from the map file to work out what to move. Alan -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80: function in RAM
On Fri, 14 Nov 2014 10:33:26 +0100 Hynek Sladky wrote: > Thanks for Your reply. > I am not sure if I understand it correctly. When I need to compile > source, code should be in INITIALIZED section to get correct addresses; > INITIALIZER section will contain .ds with correct size just to make > place for initialization data after special utility is executed - this > below mentioned utility should move this data to this place in > INITIALIZER section. Startup code then takes data from INITIALIZER and > moves it back to RAM to INITIALIZED section for run-time. Do I > understand it correctly? Is it possible to download Fuzix source (at > least these low-level parts) to get inspiration? Yes - sdcc builds with the INITIALIZER section holding the data, but with all relocations for the INITIALIZED section. You simply take the INITIALIZER section of the sdcc output and move it to the INITIALZED section when creating the final binary, then you don't need to do anything in the start up code. See https://github.com/EtchedPixels/FUZIX/blob/master/Library/tools/binman.c This reads the map file and the makebin output of the ihx file sdcc generates. Note that the binman example there makes some assumptions about how the memory is laid out by the crt0.s and bits I use. There's not really a lot to it on Z80 beyond makebin and moving the block as the bugs in the sdcc ihx output don't affect anything under 64K long. Alan -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] SDCC and 8080/8085
Has anyone done any work on this before I start randomly fiddling ? Looking at the SDCC tree the gbz80 port actually appears to be pretty close to what is needed for 8080 (asm mnemonics conventionally used are different but the actual instruction set is) and also to generate remarkably good code for such a limited CPU. >From some initial scoping it seems that for Sdcc output the differences that matter are - no LD x , (HL+) or (HL-) which is fine because they are semantically identical to the two instruction sequence with the following INC (as INC 16bit doesn't touch flags) - 8080 has in/out - no shortforum loads to 0xFFxx not a big deal, as we don't have I/O in this way and Sdcc doesn't seem to use them - no LDHL SP, #n becomes ld hl, #n add hl, sp I think - no bit instructions and arbitrary register shifts (basically no CBxx) Looks harder to deal with, particularly the top bit testing stuff. Any shifts have to go through A, so the usually generated stuff for rla (hl) inc hl rla (hl) doesn't work but needs to be ld a, (hl) rla ld (hl), a inc hl etc ditto for bit operations, you end up with ld a, (hl) ; or ld a, b and 0x80 stuff so need a clear a lot more than a gbz80 or real Z80 - no swap r, (hl) but fortunately I've not found that in any sdcc output 8) - interrupt stuff is different ret not iret, no way to stack the existing interrupt state from the hardware (much like an NMOS Z80 in fact where ld a,i push af doesn't work reliably). And since its a strict subset of Z80, the Z80 assembler will do fine Alan -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Device utilization
On Mon, 29 Dec 2014 15:20:05 + jon wrote: > On Mon, 2014-12-29 at 08:24 -0500, Joshua Lansford wrote: > > Hello, > > I understand that it is important to not overstuff a micro processor > > design to prevent the stack from encroaching on other variables and > > causing intermittent corruption that might be hard to detect and > > difficult to diagnose. > Just as point of interest: > > On most CPU where the stack works down until it hits the top of the > variables it is pretty easy to detect. Just stick a known value at the > end of the variables and test its value in the main loop to see if it > overwritten. I have done this many times over the years, also moving the > value around lets you detect corruption caused by out of bounds array > references and similar. PIC18 can be a bit easier. If he means the internal stack then it's got over/underflow bits (see the chip docs). For the external RAM you can put guard variables, you can also run it on a good simulator and set watchpoints, or on a crap simulator and set the stack to a magic pattern (eg 0xA5A5) and look to see how much of the pattern is left. Alan -- 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 ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Licence issues concerning modfied z80.lib
On Mon, 19 Jan 2015 19:43:31 +0100 (CET) Brian PEARCE wrote: > Hello, > In order to facilitate use of SDCC on my Amstrad CPC emulator I modified the > putchar routine in z80.lib using Microsoft's debug.exe. Can I share > information on how to modify z80.lib with other Amstrad hobbyists or would > this infringe the FOSS licences described in the COPYING.TXT and COPYING3.TXT > files accompanying the SDCC package? > Best regards, > Brian Well its not my software but since nobody else has replied a generic answer #include The FOSS licenses talk about modifications in the preferred form, so if you were to distribute binary patched code as opposed to just rebuilding it with the correct source change then it might be a problem (as well as being very odd given you have the source code!) If you are just distributing instructions along the lines of "get sdcc, load z80lib, go to byte 3215 and set it to 0x4E" then for small changes I doubt you are doing anything that would even count as distributing sdcc. Of course the more interesting question is this - If its an emulator why won't it run the code unmodified - If it needs a change why not submit the source level change to the SDCC project and/or make that available too Likewise you could even distribute a z80.lib and modified sources yourself. Alan -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z180 port status?
On Sat, 31 Jan 2015 08:31:42 +0100 Philipp Klaus Krause wrote: > On 31.01.2015 06:47, Dave McGuire wrote: > > On 01/26/2015 04:51 PM, Philipp Klaus Krause wrote: > >> When I get around to do some more work on the Z80 port, the Z180 > >> port will also benefit from it. I intend to particularly look into > >> more flexible handling of registers a and iy to improve code > >> generation. Any plan to use hl' de' and bc' for long values ? (ie add hl, de exx adc hl, de exx ) rather than tending end up generating 4 8bit add/adc's using (ix) Alan -- 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/ ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z180 port status?
> AFAIR some users want to keep the second register set reserved for > interrupt handlers or syscalls. However once we have the more flexible > handling of iy we will be able to generate code like > > add iy, de > adc hl, bc > > for 32-bit additions. That will certainly help in a few cases. I can understand why some users want to keep the alternate registers free, but for those who can use it the lack of them really hurts the 32bit code gen. Alan -- 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/ ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z180 port status?
> I admit to not having looked at the documentation for some time but > could sdcc not have a "reserve" switch. A really powerful option would > be to have the compiler not use a register, or reserve a register set on > on a per arch basis depending on the switch options, this would apply > all the way through (IE compiler and optimiser). gcc does it with register globals - which are extremely useful on a CPU with a lot of registers, but not otherwise. > I can see lots of problems, push all might get complex as it would > suddenly turn into push all except - or maybe pop all but backup and > restore this register register around it, the mind boggles I did look briefly at the code consequences and concluded it was way outside anything I was going to fiddle with in sdcc (I'm still trying to finish debugging 8080 support). > PS I think the compiler should have per op-code clock cycle knowledge > and macros for delays like the powerful but piss poorly documented > CCS-PIC C compilers [#use delay (clock=) and delay_ms macros] sdcc does - within the limits of not knowing the actual memory latencies and wait states, only the CPU timing. On a non wait-stated Z80 it's model is pretty damn good. It does now and then move 16bits between registers with push then pop which seems odd timing wise but I don't have a small demo case for it yet. Alan -- 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/ ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Optimizing code for PIC18F
> 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 based on code > size and the execution path assumption). > > Without testing conventional wisdom would have led me to > believe that the macro version would be much bigger than > the subroutine based one. I'm not actually surprised and I've seen similar in Z80 code generation. SDCC isn't bright enough to do massive inlining of functions which means it's also not bright enough to then realise that i is a constant in each case. Very few compilers except gcc will figure that one out unaided. Your first version can generate constant loads, the latter has to do indexing to compute a pointer and then add on offsets. You might also want to compare passing &g_stepper_states[i] instead in the function case. It ought to produce the same results but SDCC doesn't always figure that out (and in some cases such as assignments it can't always do so due to the rather braindead aliasing rules in C). The asm approach on many processors would be to use self modifying code but sdcc (probably quite sensibly) doesn't do this even on those it could 8) Alan -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Passing function arguments in registers on z80 and related, etc
> __z88dk_fastcall and __z88dk_callee > > The first one can be used on functions that have exactly one argument of > at most 32 bits. This argument will be passed in the lower bytes of > dehl. It is now fully supported in sdcc. Is there a way to tell it to use __z88dk_fastcall for all functions that fit this property ? > The second one omits the stack cleanup for stack parameters in the > caller. It is currently only supported on the caller side (and thus only > useful for calling hand-written asm functions). It's also a little bit exciting to debug when you have casts on functions that change arg types/counts but once its in is something I can use too (it's already how the 6502 compiler works) > Please use sdcc 3.4.3 #9218 or later if you want to try these calling > conventions. I'll try and take a look soon providing I can persuade SDCC to do it automatically. If not I'll at least bodge up some tests to see what the numbers are like. The old Hitech compiler still wins over SDCC on some of my code, and its mostly down to arg passing. I have a feeling that supporting two arguments of 16bit in HL and DE might also be a win for Fuzix but I've no idea how it generalizes. Alan -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How do your interrupt handlers look like
On Wed, 29 Jul 2015 09:28:08 +0200 Philipp Klaus Krause wrote: > I wonder how interrupt andlers written by sdcc users look like, in > particular: > > * Do they contain divisions? > * Do they contain multiplications? > * Do they contain pointer arithmetic? > * Do they contain array accesses? > * Do they contain shifts? > * Do they call other functions? > * Are those other called functions static? > * Do those other called functions contain divisions? All of the above in my case however I'm not currently running on any processor with hardware divison and re-entrancy problems. With the complexity of the code, amd the need to handle CPU errata which SDCC doesn't I'm also using my own interrupt state save/restore code on SDCC, gcc and cc65 anyway. I do handle various expensive "non standard" re-entrancy problems with some of the other processor/compiler pairs I use and from my perspective if its expensive but documented how to do it by hand then that's all I care about. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How do your interrupt handlers look like
> The information might be useful in improving a workaround for a hardware > division issue (see bug #2401, RFE #448 / 449). As a ps to this, I think the question is a bit wider (although I note you fixed the bug anyway). An interrupt in a divison which causes a context switch with any kind of taskswitcher/threader will also break when there is a divide in another thread that is scheduled. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How do your interrupt handlers look like
> > An interrupt in a divison which causes a context > > switch with any kind of taskswitcher/threader will also break when there > > is a divide in another thread that is scheduled. > > I am not familiar with context switches. I guess they would have to be > implemented in asm or relying on behviour that is undefined in C. Ditto interrupts. They are usually implemented in asm, and your analyser proposal would I think work because any task switcher would either use asm or longjmp() and thus make a function call. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Dropping support for labels at the end of compound statements
On Tue, 11 Aug 2015 16:16:43 +0200
Philipp Klaus Krause wrote:
> In standard C, each label has to be followed by a statement. HTis makes
> a difference at the end of compoud statements.
>
> Not allowed:
> {
> label:
> }
>
> Allowed:
> {
> label:;
> }
>
> SDCC currently allows both. The comment in SDCC.y makes it clear, that
> this is a deliberate extension.
It's one almost every compiler accepts from the original K&R compiler
through to gcc (although in more pedantic modes gcc bitches about it
nowdays)
> I would like to drop support for this non-standard extension. IMO
> non-standard extensions should only be supported in SDCC where they
> provide a substantial advantage, which IMO, is not the ccase here.
It's "defacto" C even if not standard C. I don't think describing it as
an "extension" is even an accurate description. It's tolerating a 'quirk'
of the language much accepted by compilers.
Does it cause complications to make it just warn instead ?
Alan
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 code in RAM
On Fri, 04 Sep 2015 14:05:18 +0200 Hynek Sladky wrote: > Hello, > > I need to run assembly code in RAM. Is there any way how to write such > source code? I need the compiler to produce "initialization" data in ROM > which will contain the code with all addresses calculated for RAM > placement, so the code can be a part of initialized data... Mostly it's easy. SDCC was making a horrible mess of statics initialized inside a function by generating code to init them, so on Z80 so avoid those but otherwise: Build the binary with the SDCC tools putting the initialization data somewhere unused. Copy the initialization data over the initialized data locations in the binary with a tool on your compiling box And done.. Fuzix does this (and some other stuff) but take a look at the binmunge tools on the Fuzix git tree, particularly the one for applications. If you have to them sorting the static initializers out involves running the app on an emulator, snapshotting just after the constructors and initializers run and then dumping that back out and using it on the real hardware. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 code in RAM
> I don't think we have any compiler support for that. So I recommend: > Use the -b flag for the linker to get the symbols for code in RAM, and > some tool such as objcopy to move it into ROM. Then in your main(), do a > memcpy() to move the code form ROM to RAM, and then call it. If you do then it would be useful to support that in both directions. Being able to tell sdcc to just put the data in __INITIALIZED with no funnies would also eliminate the binmunge stuff I do in Fuzix in order to go the other direction. Being able to get the relocation data without patching the linker would also be very useful. Currently you need to run one of the patched linkers for this (eg http://cpctech.cpc-live.com/download/link.zip ) Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 code in RAM
> Copy the initialization data over the initialized data locations in the > binary with a tool on your compiling box > > And done.. And yes sorry I didn't read this carefully enough the first time to realise you were doing the code not data. The theory is the same but move the code in your tool from its RAM location to ROM with a straight copy. Put a small memory copier at the start in its own segment that copies the C code to RAM and then jumps. Don't try writing the memory copier in C because you'll call inline functions in the RAM which are not yet in the right place! Providing you link it where you want it to end up the chunk of code generated is already relocated correctly and can be stored as a block anywhere you want, provided you then copy it to the right address before executing it. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] sdasZ80 and undocumented instructions
On Thu, 01 Oct 2015 07:30:39 +0200 (CEST) "Vaclav Peroutka" wrote: > Hello all, > > I got some old Z80 assembler source code and tried to compile it with SDCC's > assembler. sdasz80 speaks a very strange dialect of Z80. If you are just working with Z80 assembler then there are much better free assemblers. If you want to mix it with SDCC then the main oddities are ld a, const has be turned into ld a, #const ld a, (ix+3) into ld a, 3(ix) and the use of .org usually makes no sense because you set the addresses using linker scripts. That's much more flexible and powerful. > mumak47.20141226.asm:249(http://mumak47.20141226.asm:249): Error: .org > in REL area or directive / mnemonic error > mumak47.20141226.asm:262(http://mumak47.20141226.asm:262): Error: .org > in REL area or directive / mnemonic error > mumak47.20141226.asm:262(http://mumak47.20141226.asm:262): Error: > missing or improper operators, terminators, or delimiters > > On those lines, there are SLS D and SLL D instructions. SLS and SLL are not official Z80 instructions, nor do they work on all the platforms that SDCC targets as "Z80". You can probably fudge most of these using the .macro feature of the assembler rather than changing the assembler. If you are just working on old asm and expect the usual format then take a look at zmac. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] STM8 RAM code execution
> I implemented an unused routine which contains N _nop_ operations. But > isn’t there an easier way, e.g. "const code byte buf[N]“ or so…? PS: if you need to force this bit you can either make it a string (at least most SDCC ports currently stick strings in code not const which I guess is really a bug not a feature) Or make the include and array their own C file and use --constseg on it. Consts should usually end in flash anyway though. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] STM8 RAM code execution
On Fri, 2 Oct 2015 18:58:20 +0200
Georg Icking-Konert wrote:
> hello all,
>
> may I bother you again with a question about how to execute code in the RAM
> of STM8…?
>
> For routines in RAM (as mandatory for STM8 flash block write/erase), I
> understand the steps are:
>
> compile & link routine for address in RAM —>
> works now using #pragma in C code and —codeseg for linker (see
> [bugs:#2421]; thanks to Ben Shi!)
>
> tell linker to reserve flash space for above RAM routine (required for step
> 3) —>
> I implemented an unused routine which contains N _nop_ operations. But
> isn’t there an easier way, e.g. "const code byte buf[N]“ or so…?
It's not entirely pretty but for similar things I do the following
fairly portable sequence:
link the program for RAM
turn the binary code block into C format hex with a tool like xd
and then do
const uint8_t download[] = {
#include "downloader.hex"
};
then just memcpy it into place
and you can have the Makefile do all the steps as needed in the right
order.
Alan
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Should malloc() and friends be reentrent?
On Tue, 06 Oct 2015 17:35:36 +0200 Philipp Klaus Krause wrote: > We are planning to replace SDCC'c current two memory allocators by a new > one. In one of the curent two (used in mcs51, ds390, hc08) malloc() and > friends code is in a critical section, in the other, it is not. > > We have not yet decided which way the new allocator should go here. > > Advantages of critical section inside malloc(): malloc() can be called > from interrupt handlers, multiple threads from OSses without any support > on the OS side. > Advantages of malloc() not having critical sections: Lower interupt > latency, since malloc() can then be interrupted. > > When malloc() does not have critical sections, it is still possible to > get the advantages and disadvatages by wrapping all calls to malloc() in > critical sections (like e.g. the pvPortMalloc from FreeRTOS does). I would personally favour that the default behaviour is that it isn't interrupt safe. If it is interrupt safe and I need very tight IRQ latencies I can't fix it, whereas if I need IRQ protection and the library is not IRQ safe I can fix it In my perfect world I would do sdcc -DTHREADSAFE_MALLOC or similar and the header files would magically make malloc either a direct call or defined to a wrapper in the C lib. The other question is how correct the critical handling on the platforms is - did the Z80 port get the critical handling fixed so it works reliably on all processors ? Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Multi bank support for gbz80
On Thu, 29 Oct 2015 14:02:16 -0500 Karl Kirch wrote: > Currently trying to get SDCC up and running on some gameboy dev and am > trying to get multi bank support working. > I can get code up and running in a single bank and can get the compiler to > generate the correct code segment code using `#pragma bank 1` (will > generate `.area _CODE_1`. > The problem I'm seeing is at the linking stage. I want to put the bank 1 > code outside of the 0x address space so that it can later be swapped in > by the MBC. When I go to set the location via `-Wl-b_CODE_1=0x1` all > this does is wrap the code location back to 0x. Even when I don't set > the location explicitly I end up getting a location of 0xC131 which causes > makebin to explode because the rom size is > 32kb > > Am I missing something here? or are >32kb roms just unsupported by SDCC? I never managed to figure that out for gbz80 either, however if they are not then I've got some small patches to the compiler that handle full transparent code banking for Z80, plus some disgusting hacks to the linker. If it turns out gbz80 doesn't support > 32K ROM then I'd be happy to work with you as someone who knows the gameboy dev stuff to fix my patches/hacks to work on gbz80 as well. Some day I'll submit the bits to SDCC proper but right now while the compiler patches are clean the linker stuff is not fit for submission. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Multi bank support for gbz80
On Thu, 29 Oct 2015 15:46:10 -0500 Karl Kirch wrote: > After some more investigating it looks like this may have something to do > with the ihx step in the linker. > It appears that the extended addressing (which seems to control the larger > address space) is only enabled for `TARGET_IS_8051` and `TARGET_IS_6808` > (see > http://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/sdas/linksrc/lkihx.c#l150 > ) > > Gonna fiddle with this a bit to see if that's the culprit for why the > address space is wrapping for gbz80. > > This is grasping at straws though... It wraps because the gbZ80 only has a 16bit address space, as well as the -r flag. Been there done that already when doing Z80 banking. I also started that way by hoping that adding 64K to each 'bank' would produce a binary that was linked properly but exportable easily. In the end however I had to modify the linker to output a new format with each bank linked at the same address (where it will be banked into) and output the banks to separate files. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] wchar_t
On Sat, 14 Nov 2015 17:17:33 +0100 Philipp Klaus Krause wrote: > Dear SDCC users, > > are you currently using wchar_t? No. > will you want to use wchar_t in the future? On Z80 probably not Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] z80 target, code-loc/data-loc
> According to documentation, if I don't use --data-loc, the location is > set to "as low in memory as possible". I don't know what this would > result in with zx spectrum, where the low 16k is ROM, next 6k or so is > display memory, and the 16k-32k is "slow memory" which one would > probably avoid using if possible.. It would be nice if there was an > option to calculate and place the --data-loc right after code ends. If your crt0.s lists CODE then DATA (as is normal) then it will put the data and the like directly after the code unless you specify a --data-loc. So if you specify --code-loc 32768 and don't specify a data-loc or have one in the linker file it'll pack code/cost/data/etc with all the free memory at the top. If you use linker scripts you can also add other segments and pack them in different places (eg to link a table in the printer buffer on the spectrum or build some code into the slow memory space). The only thing to watch is that sdcc on Z80 does not put all constant text strings in CONST, some of them end up in whatever section that piece of code is in. That seems to be a be an SDCC bug but doesn't usually matter. Also take a look at the address spaces stuff - that will let you handle banked data on the 128K machines. I've got a few add on patches and linker hacks that will build Spectrum 128K banked binaries as well so you can use upper 16K banks for chunks of code. Alan -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] A floating-point type cheaper than float
On Mon, 11 Apr 2016 20:10:17 +0200 Philipp Klaus Krause wrote: > Dear SDCC users, > > SDCC currently implements 32-bit float as its only floating-point data type. > > Would you like to see a cheaper one in SDCC, that uses only 16 bits? Not that I can think of for Z80/Z180. I'd be using fixed point and/or lookup tables. I can see it might be different for faster microcontrollers and other applications. Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] A floating-point type cheaper than float
> on MCUs without a hardware implementation. On these small MCUs, > fp is slow and I was arguing the only meaningful gain could be > in code size but I don't think there would be much difference in > code size between a short float and regular float implementation. Fpr a lpt of these devices the gain would be between using existing OS provided (non IEEE) 'short float' formats. Right now for example on the Sinclair machines there is a full rather nice non IEEE floating point built into the ROM but while it's useful it's rather "interesting" to use from SDCC. Similarly on the Amstrad CPC boxes. For me "short float" or similar would actually be useful as a "native non IEEE" format indicator - but then you've got to know how to encode floats and what the target float format is which is a large can of worms. Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] A floating-point type cheaper than float
On Wed, 13 Apr 2016 00:25:23 + alvin albrecht wrote: > >SDCC currently implements 32-bit float as its only floating-point data type. > >Would you like to see a cheaper one in SDCC, that uses only 16 bits? > >Would you use it? > > > My answer is yes, sort of (fuller explanation below : ) > > > For any 8-bit microcontroller without hardware floating point, floating point > is not about performance it’s about convenience. Agreed for the general case - in fact I'd have more use for 64bit bit doubles even if rather slow 8) Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] A floating-point type cheaper than float
> For the spectrum, cpc and other machines, their float implementations are > not technically "short". Without having a closer look, I think most > are 32-bit which is the same size as SDCC's current float and IEEE single > precision. The ones I've used are mostly 40bit (TRS80 uses 32 and 64bit) > In this scheme how is SDCC told which float format encoding > to use and who is responsible for defining them? Another poster > mentioned SDCC may not want to clutter itself with a bunch of > legacy requirements. If that's the case, perhaps SDCC could > supply a mechanism and then the library implementers could > maintain float conversion code for the float types the library > implements. That would make a lot of sense to me - and it also covers cases where you want to take the hit of full IEEE 64bit double - because it's just another format and library. Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Interrupts on Z80 and Z180
> We generate code: > 1) > save regs > ... > restore regs > reti > 2) > di > save regs > ... > restore regs > ei > reti > 3) > save regs > ... > restore regs > retn > > Out of these, 3) looks correct to me. But 1) fails to reenable > interrupts at the end (I think there should be an ei before the reti). > And 2) is completly wrong, I think it should be: > ei > save regs > ... > restore regs > reti > > Did I miss something? When I looked at this ages ago I came to the same conclusion but never worried about it as I couldn't use those methods anyway because I needed to be able to save/restore interrupt state. Of the others Your changes to #1 are IMHO correct You can't implement #2 on a Z80 this way #3 appears to be correct (as far as it goes for Z80) For the #2 case you can't do the ei because on many platforms (eg MSX) you'll immediately take another interrupt and execute nothing but ei push af irq entry ei push af irq entry until you crash. The #1 case is only safe because the ei takes effect the instruction after (ie after the reti), a detail quite a few emulators get wrong The general case of a Z80 interrupt handler that can be re-entered is irq_entry: push stuff save state from interrupting device ack interrupt source on priority aware controller ei process state from device pop stuff ret In some situations you even end up having to do stuff like irq_entry: push stuff save state from interrupting device push dummy_ret ei reti; acks the IRQ returns to the next instr dummy_ret: process state from device pop stuff ret Neither of those can be expressed in a function entry annotation Z180 is different again because you've got multiple IRQ sources and something resembling onboard interrupt controllers. Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Interrupts on Z80 and Z180
> What's the problem with the interrupt state? The interrupts are > unconditionally enabled, but since we're in an interrupt handler, they > were enabled before. There should be no need to save/restore state. > Any other reason why __interrupt is not suitable for you? I wouldn't call it a "problem". I think my use cases simply go outside the simple models. There are two reasons I care about it 1. I have code that includes routines sometimes called within critical sections of other code sometimes not, and those routines may also have their own critical sections. 2. Because I am multi-tasking I sometimes task switch on an interrupt between a process that had interrupts on, to one which has interrupts off but voluntarily gave up the processor. In that case my interrupt entry and exit are intentionally different. And for the cases where I have to do stuff like ack an IRQ and enable interrupts I need to control the interrupt state directly. What I actually use is the same model is pretty much every Unix ever did (although I need to add IRQ priorities to it now I'm tackling 68000) irqflags = di(); [code] irqrestore(irqflags) and also a function ei(); Those are tiny bits of Z80 (except for the NMOS Z80 with the irq erratum) and I can also implement them trivially in other compilers as I'm building the same core codebase with gcc, cc65, bcc, sdcc. Hopefully that explains why - but I really don't see it as an sdcc flaw or weakness - my usage is a special and unusual case. If I was doing the typical embedded single target programming then the (minus the Z80 NMOS bug) sdcc would fit perfectly. Alan -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC 3.6.0 Release Candidate 1
On Tue, 31 May 2016 00:09:01 +0200 (CEST) "Maarten Brock" wrote: > Hello SDCC followers, > > Today the first Release Candidate (RC1) for SDCC 3.6.0 has been created. > As always it has been put online in our SourceForge File section. > https://sourceforge.net/projects/sdcc/files/ > > If you have the time, please verify it and report back with the positive > or negative results. The positive: l9x now builds without weird type errors that were present on 950x Code generation for compactness at least is again way better on Z80. The Bourne shell was 25762 bytes last time I looked and is now down to 24354 (assuming of course it still works when I get round to testing!) Almost everything still builds for the Fuzix C libraries and application set, which is becoming a fairly large chunk of code. The negative: calendar.c:233: warning 84: 'auto' variable 'retval' may be used before initialization Caught signal 11: SIGSEGV m4.c:485: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '4224' : code generator internal error Contact Author with source code m4.c:485: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '4224' : code generator internal error Contact Author with source code In one case code that used to build now errors (correctly due to the tightening up on type specifiers) but shows weird behaviour - some of the warnings are not displaying the correct line number and show "-" as the filename: exec.c:88: error 226: no type specifier for 'i' -:0: warning 85: in function setcmd unreferenced local variable : 'len' -:0: warning 85: in function setcmd unreferenced local variable : 'i' exec.c:524: warning 85: in function backup unreferenced local variable : 'p' -:0: warning 85: in function nextfile unreferenced local variable : 'what' None of these have obvious small reproducers - is there a preferred way to send you something to debug ? Minor An implicit declaration is now followed by a confusing report about auto variables man.c:590: warning 112: function 'build_headers' implicit declaration man.c:590: warning 84: 'auto' variable 'build_headers' may be used before initialization Warnings for the common expression for (tp = tbuf; tp < &tbuf[TSIZE]; tp++) where TSZIZE is the size of the struct. Although having quickly checked those don't appear to be that new I've not done any real runtime testing but I will try and do that and also pull out some of the workarounds I have for older sdcc and see how many of those still break. So far this all looks pretty good to me for a first release candidate. I still hit the following limits (unsurprisingly) - the speed of optimized compilation for Z80 (ok it is a bitch of a CPU to generate code for) - code generation (way better than any other Z80 compiler but still some real facepalm grade code generation in there and often for trivial easily optimised cases like 16bit equality compares with 0-255) (*) - inability to assign structs (even ones that fit an int or pointer size), which stops me from using sdcc with yacc when %union is used Also a question: I have some nice clean compiler patches for code banking but not yet good linker ones. I don't know if you are interested in them once 3.6 is out but basically they add a Z80 compiler option which - changes the calling sequence to expect arguments two bytes further up the stack - puts text constants in const not code (IMHO this is a bug fix) - generates push af call func pop af sequences for function calls. The smart linker then replaces inter-segment calls with call _helperfunc_a_b; helperfunc is the right helper, a b ; are the banks defw func and the helpers use the extra two stack bytes to save/restore the banks when switching. Indirect calls via pointers are revectored via stubs generated by the linker. I've been using it for the Fuzix kernel on ZX Spectrum for a while and it seems to be fairly solid at this point. Thanks for all the work on the compiler Alan (*) In that case it's ld a,b dec a jr nz, false_path ld a,c or a .. where of course the second part should just or c knowing a is 0 -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC 3.6.0 Release Candidate 1
> Are any of the problems you experience regressions from sdcc 3.5.0? Couldn't tell you immediately as 3.5.0 blows up/miscompiles various other things so I've been using snapshots for ages, but from testing now - no both the compiler error and the segfault are existing problems The weird "not reporting the file name/line number for some errors" seems to be post 3.5.0. Alan -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 Assembly Development
On Fri, 19 Aug 2016 10:51:41 -0300 Augusto Fraga Giachero wrote: > Hello Peter, > > > As stated in the documentation, the ABS areas "automatically invokes > OVR" (Page 1-27, .area Directive), so (ABS) or (ABS,OVR) have the same > effect, indeed I've tried what you suggested resulting in the same behavior. > > > I think I've managed to workaround this issue in my case. I don't known > if it's the best way to solved but is good enough for me. It seems that > the sdld linker needs to be explicitly informed where to put the > different areas, so I've declared an global symbol at the end of the > boot.asm file: > > > ; boot.asm > > .globl HexToU8, BOOT_END > .area _START (ABS) > .org 0 > ldSP, #0x > call HexToU8 > BOOT_END: > > And used the linker flags "-i -b _CODE=BOOT_END -b _START=0" to inform the > start address for the areas. The other files that uses the _CODE(REL,CON) > area the linker relocate them as expected. It should be sufficient simply to link the startup module first with the start code first in the code segment and just leave _CODE as 0. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] Sdcc-user] Killing z80 peephole rules
On Mon, 2 Oct 2017 13:46:12 +0200 Philipp Klaus Krause wrote: > Dear users of the z80 backend, > > I intend to remove some z80 peephole rules. You might want to check if > you are affected (by compiling your source usign current SDCC 3.6.9 > #10025 or later with --fverbose-asm, and checking the output, e.g. using > a command like "grep peephole 21c test.asm". > > While peephole rules are a quick way to get a bit of optimization, often > improvements in code generation and register allocation can result in > even better code (and also make old peephole rules obsolete). > > None of these rules is currently used in the regression tests for z80. > > Keeping unused and untested rules comes with a maintainance burden and a > risk for bugs, so rules that are no longer used should be removed once > in a while. > > If one of the rules that I want to remove happens to be used by SDCC > when compiling your code, please report on the list, and I well keep it. > Ideally, you would also provide a small some compileable source example > that SDCC uses the rule for. > > Here is the list of rules to be removed: Fuzix uses 49g, 141a. 49f and 49f' are I assumne different ? 49g turns up in powf() in the C library severa times, and in soem device drivers 141a turns up in driver code for the kernel in a few places (eg sd_spi_init for socz80) ld c, #0x14 ; genLabel 00131$: ;../dev/devsd_discard.c:93: sd_spi_receive_byte(); /* send dummy clocks -- at le ; genCall pushbc call_sd_spi_receive_byte pop bc ;../dev/devsd_discard.c:92: for (n = 20; n; n--) ; genMinus ; genIfx dec c ; peephole 141a removed redundant transfer and flag setting in a jr NZ,00131$ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Sdcc-user] Improving the IDE integration of SDCC
On Mon, 1 Jan 2018 19:05:44 +0100 Philipp Klaus Krause wrote: > While many users of SDCC - including myself - typically do not use an > IDE together with SDCC or do not need tigher integration of the IDE they > use with SDCC, better IDE integration seems to be a common request. > > AFAIK, the only IDEs with SDCC support are Code::Blocks (out-of-the-box) > and Eclipse (via an old plugin). I have documented the current state at > http://sdcc.sourceforge.net/mediawiki/index.php/IDE_integration. > > I guess the next steps could be: > > * Update the Eclipse plugin to work well with current Eclipse and SDCC > for many of the architectures targeted by SDCC. Another thing would be to enable sdcc to be told to call its object files "foo.o" not "foo.rel" and possibly to dump all the other files (listing etc) in a differenrent directory as an option. Right now the fact sdcc uses weird names (and I understand the history) makes it hard to work with a lot of otherwise quite generic tooling that expects "normal" compiler conventions but otherwise doesn't do anything particularly magic. Alan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC 3.7.0 Release Candidate 1
> * Faster register allocator reduces compilation time by about 25% (does > not apply to mcs51, ds390 which use a different register allocator). Noticably so for the most part, although the V7 dc code in Fuzix seems to have gone the other way and now takes my machine over 10 minutes and 16GB of memory to build ! With one exception everything built (see below) although I need to do more run testing and see what other than the kernel broke and why. > * New methods to obtain tree-decompositions of control-flow graphs > improve compilation time / code-quality trade-off (when SDCC is built > with support for the treedec library). Where do I find the treedec library ? Without the treedec library the code generated seems to be slightly larger although some grew, some shrunk and it's not by much. More of a concern is that the resulting kernel image doesn't boot with 3.7.0rc1, but I need to do some digging to see why. I also have some parts of my build producing the message ../../Library/tools/fcc -O2 -c uud.c used unbound variable in replacement which looks like some kind of escaped debugging ?? While the MWC originated ed command causes the compiler to crash Caught signal 11: SIGSEGV make[2]: *** [Makefile.z80:49: ed.rel] Error 1 which I need to look at getting some kind of debug for you. The mixed 16/32bit maths doesn't appear to have helped much in my Fuzix kernel cases. It still tends to try and load stuff into registers it doesn't need to (trivial example below). These btw aren't complaints - I'm just highlighting cases I've noticed that may be worth the compiler learning about. Function uoff ; - ; Register assignment might be sub-optimal. ; Stack space usage: 0 bytes. _uoff: ;inode.c:32: return BLKOFF((uint16_t)udata.u_offset); ; genPointerGet ld hl, (#(_udata + 0x0064) + 0) ld bc, (#(_udata + 0x0064) + 2) ; genCast ;fetchPairLong ; genAnd ld a, h and a, #0x01 ld h, a ; genRet ;fetchPairLong ; genLabel ; peephole 158 removed unused label 00101$. ;inode.c:33: } ; genEndFunction ret It also still doesn't figure out big constant shifts on longs. For example a static ulong being >> 9 generates a loads into four registers and a set of 9 loops of 4 shifts. GCC on 6809 instead generates 3 bytes of loads one set of shifts and a zero of the top byte. It's even more painful with big shifts. SDCC turns if (staticlongval >> 25) into a ton of loads and shifts gcc generates the 6809 equivalent of ld a,(hibyteoflong) and #0xFE and SDCC still seems to try and generate 32bit loads when told to do ((uint16_t)x) and use that for an operation. Alan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] Fw: SDCC 3.7.0 Release Candidate 1
> * Faster register allocator reduces compilation time by about 25% (does
> not apply to mcs51, ds390 which use a different register allocator).
Noticably so for the most part, although the V7 dc code in Fuzix seems to
have gone the other way and now takes my machine over 10 minutes and 16GB
of memory to build !
With one exception everything built (see below) although I need to do
more run testing and see what other than the kernel broke and why.
> * New methods to obtain tree-decompositions of control-flow graphs
> improve compilation time / code-quality trade-off (when SDCC is built
> with support for the treedec library).
Where do I find the treedec library ?
Without the treedec library the code generated seems to be slightly
larger although some grew, some shrunk and it's not by much.
Unfortunately it's now miscompiling the kernel
;tty.c:82: if (t->termios.c_lflag & ICANON) {
; genAssign
; AOP_STK for _tty_read_sloc2_1_0
;fetchPairLong
ld c, -5 (ix)
ld b, -4 (ix)
; genPointerGet
; AOP_STK for _tty_read_sloc3_1_0
;fetchPairLong
ld l, -11 (ix)
ld h, -10 (ix)
=== This points HL at the right 16bit pair
ld a, (hl)
=== A now holds bits 0-7 of the flags
inc hl
ld a, (hl)
=== A is now corrupted
; genAnd
bit 4,a
=== And this test fails
; peephole 149 tested bit 4 of a directly instead of going through l.
jr Z,00129$
I also have some parts of my build producing the message
../../Library/tools/fcc -O2 -c uud.c
used unbound variable in replacement
which looks like some kind of escaped debugging ??
While the MWC originated ed command causes the compiler to crash
Caught signal 11: SIGSEGV
make[2]: *** [Makefile.z80:49: ed.rel] Error 1
which I need to look at getting some kind of debug for you.
The mixed 16/32bit maths doesn't appear to have helped much in my Fuzix
kernel cases. It still tends to try and load stuff into registers it
doesn't need to (trivial example below). These btw aren't complaints -
I'm just highlighting cases I've noticed that may be worth the compiler
learning about.
Function uoff
; -
; Register assignment might be sub-optimal.
; Stack space usage: 0 bytes.
_uoff:
;inode.c:32: return BLKOFF((uint16_t)udata.u_offset);
; genPointerGet
ld hl, (#(_udata + 0x0064) + 0)
ld bc, (#(_udata + 0x0064) + 2)
; genCast
;fetchPairLong
; genAnd
ld a, h
and a, #0x01
ld h, a
; genRet
;fetchPairLong
; genLabel
; peephole 158 removed unused label 00101$.
;inode.c:33: }
; genEndFunction
ret
It also still doesn't figure out big constant shifts on longs. For
example a static ulong being >> 9 generates a loads into four registers
and a set of 9 loops of 4 shifts. GCC on 6809 instead generates 3 bytes
of loads one set of shifts and a zero of the top byte.
It's even more painful with big shifts. SDCC turns
if (staticlongval >> 25)
into a ton of loads and shifts
gcc generates the 6809 equivalent of
ld a,(hibyteoflong)
and #0xFE
and SDCC still seems to try and generate 32bit loads when told to do
((uint16_t)x) and use that for an operation.
Alan
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC 3.7.0 Release Candidate 1
On Sun, 11 Feb 2018 18:32:11 +0100 Philipp Klaus Krause wrote: > Am 11.02.2018 um 17:40 schrieb Alan Cox: > > > >> * New methods to obtain tree-decompositions of control-flow graphs > >> improve compilation time / code-quality trade-off (when SDCC is built > >> with support for the treedec library). > > > > Where do I find the treedec library ? > > > > > > https://github.com/freetdi/tdlib > > I only tested with the "develop" branch recently. When treedec is > installed, SDCC configure should find it. > Thanks. I try that, and I'll also stick the crash and the miscompile into the bug dbase when I get a moment. Alan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Custom crt0, makebin: error: size of the buffer is too small.
On Mon, 9 Jul 2018 01:57:44 +0200 Tomas Brännström wrote: > Hello! > I am trying to build a small gameboy application with a custom crt0 (for > now it's just a copy of the default one with some interrupt handlers added, > though I did try with an exact copy of the default crt0 also) but "makebin" > refuses to work and just tells me that the "size of the buffer is too > small". Firstly makebin defaults to a max of 32K (no idea why, I think it's just written to wind people up) so do makebin -s 65535 Secondly the linker has a weird and totally undocumented way of ordering areas, which is that they are ordered by first mention. Thus you often need your crt0 to start with something like .AREA _BOOT .AREA _CODE .AREA _INITIALIZED etc in the order you need to pack things so you don't find your code somewhere above 0xC000 or similar. Also makebin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] eZ80
On Sun, 23 Sep 2018 16:23:27 +0200 Philipp Klaus Krause wrote: > How useful would it be to have better eZ80 support in SDCC? Are there > any SDCC users that target the eZ80? Looking at it in future. Z280 is the first interest although I've integrated John Coffman's asz280 into my branch of sdcc and I'm starting to fiddle with that anyway. > There are 2 main differences between the Z180 and the eZ80: > > * ADL mode: The 24-bit address mode (). Support for this would take more > effort. Minimally useful at best. > * Z80 mode: The 16-bit load instructions (ld rr, (hl), etc). As we have > seenin the r2k and tlcs90 backends these really help with code size, > especially for handling pointers. Support for these should be much > easier to add to SDCC than support for ADL mode. That would be really nice to have, as would having it error any inadvertent instructions eZ80 doesn't have (the ld r,r re-used as prefix). (as a side note a byproduct is also useful which is being able to rewrite those real size wins in the peephole back into Z80 rst instructions for compact but slower Z80 code). I'd still like to be able to squash a Fuzix kernel into 32K on Z80, and looking at the assembler I think it would be doable but the size/speed tradeoffs are further into the size space than sdcc currently goes - plus fixing some of the more interestingly bad code generation. > How useful would an ez80 backend in SDCC, which would generate code for > the Z80 mode of the eZ80 be? Fuzix would use it as and when one of the proposed ez80 homebrew boards gets built. The only use Fuzix would make of the 24bit mode I can think of would be asm bits (hand optimized memory copiers etc) - and I can imagine it's helpful for FP. And if anyone knows of a usable ez80 cpu emulator core I can integrate into a debug platform I can do a build at some point with that and see how it goes. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDCC 3.8.0 Release Candidate 1
Nothing blew up building Fuzix, and my very minimal testing so far booted and ran. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Adding support for the 6502 processor
> Last week I got to TurboGrafx-16 game console and currently thinking how to > program it in C. My idea is to create HuCard with SD CARD and RAM. Simple > bootloader chooses the game from SD card, loads it into RAM and runs it. The HuC is not quite a 6502. cc65 supports it sort of but the HuC weirdnesses do require some care and workarounds because it places the zero page at $20xx unlike a real 6502. That in turn breaks anything that assumes zp accesses and 00xx accesses end up on the same page. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Anyone returning expressions in functions returning void?
On Fri, 1 Mar 2019 10:17:56 +0100
Philipp Klaus Krause wrote:
> The C standard does not allow returning expressions in functions
> returning void. E.g. this
>
> static void attr_rtx(char *, char *);
> static char *attr_string(char *);
>
> static void
> attr_eq (char *name, char *value)
> {
> return attr_rtx (attr_string (name), attr_string (value));
> }
>
> is not allowed by the standard. However, GCC allows it as an extension.
> SDCC also currently allows it as an extension (i.e. when --std-cXX is
> not specified).
>
> Is anyone using that extension functionality?
Not knowingly. I cleaned a few of these up in Fuzix when compilers whined
about it. If it finds any more I'll just fix them.
Alan
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] wipe out data area
On Fri, 12 Apr 2019 20:52:31 +0200 Klaus Brandl wrote: > Hi, > > is there a way to get the _DATA section to the very end, and wipe it > out on the z80 port? The order things appear is determined by what is in crt0.s. You can thus keep it at the end and rather than saving all the zeros to disk wipe them at startup. You can't get rid of it though - it's real used space. What you can get rid of is INITIALIZER by copying it into INITIALIZED with a helper tool instead of doing that at runtime. I do that for Fuzix. The other thing I do for Fuzix is I put a lot of the early start up code into a section I call DISCARD and then re-use that memory for other stuff (working buffers etc) once I have the setup completed. The Fuzix tool is at https://github.com/EtchedPixels/FUZIX/blob/master/Library/tools/binman.c and processes the binary and map file from SDCC. It builds a Fuzix header as well which you clearly don't need but does show the basic manipulations needed to bash an SDCC image into a more useful shape when running from RAM. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] spurious ld instruction on z80 port
On Tue, 21 May 2019 20:34:43 +0200 Klaus Brandl wrote: > Hi, > > i am wondering about the instruction: > > ld (hl),de > > sdasz80 from sdcc 3.9.0 generates: > > ED 1F Looks like an ez80 instruction that should have been errored. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Packed structs
On Thu, 4 Jul 2019 17:35:15 -0700
Jacob Jennings wrote:
> Hello,
>
> I am fond of using __attribute__((packed)) to document register definitions
> in this manner:
>
> typedef struct BitField {
> bool b7;
> bool b6;
> bool b5;
> bool b4;
> bool b3;
> bool b2;
> bool b1;
> bool b0;
> } __attribute__((packed)) BitField;
>
> Would I expect sdcc to generate packed structs without the attribute in
> this case? -fpack-struct=1 is unsupported, and __attribute((packed))__
> presents a syntax error.
Yes.
I ended up with a define __packed that is null for SDCC and cc65 but
__attribute((packed)) on other compilers that supported it.
Whilst it's not an SDCC concern the other problem is that some compilers
will generate safe code for packed field accesses, others don't.
Alan
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How to compile for more than 64kB ?
On Fri, 06 Dec 2019 14:21:15 +0100 (CET) "Vaclav Peroutka" wrote: > Hello, > > > > I was thinking about how to make a bigger projects where I can possibly need > more than 64kB of memory on Z80 (or other 8-bit architectures as well). > There is a memory mapper in the design and one can map 8kB segments to the > range of Z80 CPU. > > > > > Has anybody seen some method how to do it efficiently without too much > overhead ? How to set up the SDCC compiler ? I have a slightly patched SDCC and a modified linker that can do code banking and automatically bank switch that I use for Fuzix. The compiler mods are tiny but the linker is a bit more complex, and you also need to write support code for your platform. With that I've been happily running 64K of code in a 4 x 16K banked EPROM, code banked on a ZX Spectrum 128K, and 2 x 32K banks of code on RC2014 including interrupt handling and multi-tasking. For code it's not very hard. You need to solve two things 1. Adjust the stack so that you've got an extra word or so to store the bank info within the call frame 2. Generate code that can be linker patched into a bank to bank call when needed. For Z80 I patch SDCC with an option that expects an extra word on the stack from the caller, and to generate PUSH AF CALL foo POP AF The linker in turn replaces inter bank calls with CALL __bank_n_m DEFW foo or for things like tables of functions it replaces the address with the address of a stub function that does the call, and then sticks all those in a 'STUB' segment the app describes. Data banking is a different game however. If it's big chunks of data for things like game maps then often all you need is a 'far copy' function. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] banked functions for z80, z180, gbz80, etc?
On Thu, 9 Jan 2020 16:45:58 +0100 Philipp Klaus Krause wrote: > Currently, for the z80-related backends, there is some limited support > for banked functions in SDCC (for calls that do not go through function > pointers, the compiler can insert some glue code to a custom banked_call > function). > > What would need to be done to improve that? > > For Z180 and eZ80 we know the hardware. But there are still many ways to > set up stuff (different sizes of banked areas, etc). No you don't actually. There are many of Z180 systems with a flat 64K address space because the Z180 was an upgrade board to the Z80 originally present and the original banking is used. Some of the more common old ones are even hybrids (eg the XLR8R cards for the TRS80 have 256K of Z180 linear space but the base system memory is 128K banked in 32K chunks). Not as common as with 65C816 (where some poor design decisions in the CPU make it often better to use external banking) but still not unusual, and in fact present even on current retrobrew hardware when you for example put a Z180 CPU board in an existing RC2014 Z80 system. > For Z80 and GameBoy we don't know anything: There are many different > bank layouts and ways to switch banks. > > What I would like is: A flexible scheme that allows code in banked > memory, and also supports function pointers. > Banked code should be able to call nonbanked code, code in the same or > in other banks. > > Should there be support in the linker? If yes, in what form? > > What does FUZIX currently use? Fuzix does the following 1. A small patch that adds a compiler option to selecte 'banked' compiles This just changes the argument offset on the stack by two bytes, and causes the compiler to emit push af call foo pop af for function calls. The existing stuff to set the code segment name is used so you compile stuff into _CODE1 _CODE2 _CODE3 etc (and some names for common). The compiler piece is trivial but important because those extra two bytes are essential in order to make bank unwinding work properly in all cases. 2. Some hacks for the linker (and these are currently rather Fuzix specific so would need cleaning up) The linker hack uses the segment names (some of its it is hackish in the sense the linker stuff is hardwired for some fuzix names like COMMONMEM VIDEO FONT etc too). The linker looks for calls that go between banks or banks and common If a relocation is from code to code then it swaps the push af/call/pop af with call __bank_n_m ; where n/m are the banks .word funcaddr and the platform provides specific banking functions according to need. The extra push/pop af is removed and the extra 2 bytes on the stack are needed by the bank switching code (it uses it to push the address of the correct stub to switch back) If a relocation is from data to code then it generates a small piece of new code in the STUBS segment (in common) that does the inter bank call and uses that address. To ensure function pointer comparison works and to save space two references to the same function via data use the same stub segment entry. There is a little bit of additional linker ugly here in my changes to deal with the case of ld hl,#funcaddr type stuff the compiler generates. The actual linker relocation changes are pretty simple. What is hackish is a) the way it turns names into banks and b) the way I generate the output - I should have written a new linker output file format but I just hacked something together outputting ihx files with the bank number then the ihx data, and a tool that turns it into a bunch of ihx. The other thing the linker code do with btw is the ability to output a relocation map so you can make relocatable binaries nicely with it. Right now I link it twice and tools analyze the binary to generate Fuzix relocatable binaries or CP/M object files. 3. Not needed for Fuzix because I only bank the kernel at this point so not present - setjmp/longjmp support for bank switching on the longjmp. I have this in use on a variety of systems with both simple cases (2 x 32K kernel banks) to complex setups like the ZX Spectrum 128K with 4 x 16K banks of kernel code in the same window, and in ROM with the Tom's SBC design where the kernel is banked 4 x 16K in EPROM in the low 16K. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] banked functions for z80, z180, gbz80, etc?
> > The compiler piece is trivial but important because those extra two bytes > > are essential in order to make bank unwinding work properly in all cases. > > Why do you need two bytes? I would have guessed that one should be enough. To avoid magic wrappers everywhere. The bank helper for that switch pushes the address of code that switches back to the calling bank and then does a ret. This means that the far function is completely unaware of any magic. It does a ret, it ends up in the code that switches bank back, which does a ret which ends up where expected. > The approach of essentially treating all calls as banked is interesting. > Maybe this could be implemented as a new memory model (e.g. > --model-large, similar to how this is implemented for stm8, making > function pointers 24 bits). > > I'd still like to have banked calls in the normal memory model, handled > differently from normal calls. Yes - doing it as a generic thing has a performance impact. For my use case that's fine and it would be unmanagable any other way. Something like a game specific to one platform would want explicit banking in many cases I think. The explicit banking case is also very useful for the classic disk overlays model. When you have your bank switches planned and few of them it's an identical problem to the disk overlay model. > > > > > The linker looks for calls that go between banks or banks and common > > > > If a relocation is from code to code then it swaps the push af/call/pop af > > with > > > > call __bank_n_m ; where n/m are the banks > > .word funcaddr > > > > and the platform provides specific banking functions according to need. > > The extra push/pop af is removed and the extra 2 bytes on the stack are > > needed by the bank switching code (it uses it to push the address of the > > correct stub to switch back) > > > > So you have one stub per bank? One per combination although in fact most of them merge together because every function calling into a bank has the same tail code, but a different pushed value. The end result is one per combination for about 8 bytes then merging into one per bank, and one per bank for returns, plus some for the stub stuff as it's a shade different. In terms of them all being the same, the Rabbit is explicitly designed to do it differently and the 'official' rabbit compiler generates code which is designed to run in an 8K sliding window, and has long jump/call/ret instructions including linker inserted ones for functions that cross an 8K boundary. That model is also doable on Z180 but a bit more clunky (and I think came from some Z180 use cases and tools). In that model you don't have to worry about dividing stuff into banks by hand. You have data and common stuff, and a sliding 8K window for the rest. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] banked functions for z80, z180, gbz80, etc?
> 5. Add optimization to compiler to replace calls to ABS address (n*8, n= > 0...7) by corresponding RST instruction (someone may want put banked_call > on one of RSTs). This makes sense but the last one is very non-portable, and instead you can do it with a custom peephole file to suit your target. The other problem you have is you are changing how some functions are called but not all. That will break function pointers unless you also type them somehow. > > Example: > _caller:: > push ix > ld ix,0 > add ix,sp > ld hl,4 > add hl,sp > ld sp,hl inc sp inc sp inc sp inc sp is simpler as is just pushing a random register twice. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Data area immediately following code
On Wed, 1 Apr 2020 18:01:37 +1100 Brad Robinson wrote: > Hey All, > > I've got a Z80 project where the generated image will be loaded > directly into RAM and therefore the initialization data doesn't need > to be copied from the image to a specified RAM area. > > How can I configure SDCC to generate an image like this? A working > example would be great. I've not found a way to do it, which is a bit of a nuisance as SDCC also generates a load of garbage initialization code it doesn't need to for many static objects inside functions. Currently I keep the statics outside functions to avoid the pointless code, put the initializer segment somewhere out of the way, and wrote a tool that simply copies the initializers into the right place in my binary. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Data area immediately following code
On Fri, 3 Apr 2020 11:06:32 +1100 Brad Robinson wrote: > Thanks guys. > > I really don't want to have to install an additional toolchain if I > can avoid it. > > I just discovered the following messages which provide some seemingly > relevant clues but doesn't really address collapsing INITIALIZER and > INITIALIZED areas into one: > > https://sourceforge.net/p/sdcc/mailman/message/34781898/ > > I guess I need to dig into understanding the linker scripts and see if > I can figure it out. The SDCC linker cannot as far as I can tell do this. Even if you tell it to put them both in the same place you don't know which one will end up there. See https://github.com/EtchedPixels/FUZIX/blob/master/Library/tools/binman.c which is how I work around this ugly limit for Fuzix. The Fuzix one also patches a header block with things that the SDCC linker is not able to resolve itself (which to be fair is a limit it shares with a lot of linkers except cc65 and lwtools for 6809). but you can just ignore that bit. There are also tools in that github for generating relocatable binaries. Another thing to check is whether Z88DK has addressed this. It uses a modified SDCC as the main compiler and if so you could just switch to Z88DK instead. > > SDCC uses very simple scheme for storing initialization data. There are also seperate initializers in code generated for some stuff which waste tons of space. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How to move string literals to const area (Z80)
> I don't remember if the z80 backend has support for separate const and > code segments already. If it does, #pragma constseg or --constseg would > be a good solution. It half works. There's an open bug about it somewhere. I fixed the one half that mattered most to me and that got merged but the other cases when I tried tracing them I couldn't figure out wtf was going on. It's not just strings that are broken though. Some const objects end up in data space and it can even depend upon the order of reference and use it seems. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How to control segment placement from C?
On Sun, 26 Apr 2020 21:01:45 +0200 Philipp Klaus Krause wrote: > Assuming I have a space_a segemnt that I want placed directly behind the > DATA segment, i sthere a way to do so from C code (i.e. without using > linker options or linker scripts)? With a custom crt0 you can do it, but you need to go to the asm level. The linker sticks the segments together in the order they are first mentioned - except when it doesn't: _CODE is a bit weird. My Fuzix crt0 files start with stuff like ; Ordering of segments for the linker. ; WRS: Note we list all our segments here, even though ; we don't use them all, because their ordering is set ; when they are first seen. .area _CODE .area _CODE2 .area _VIDEO .area _CONST .area _INITIALIZED .area _DATA .area _BSEG .area _BSS .area _HEAP etc, to force the order I want. The default crt0 does the same trick in order to get GSINIT/GSFINAL right. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] How useful would arbitrary-width integers be?
On Mon, 12 Oct 2020 17:25:55 +0200 Philipp Klaus Krause wrote: > I wonder how useful arbitrary-width integers would be for SDCC users. > > _ExtInt(N) would be an N-bit integer type. > > E.e. one could have an unsigned 24-bit integer (in 3 bytes) via > > unsigned _ExtInt(24) i; > > or a 23-bit type (3 bytes in memory, 23 value bits and 1 padding bit): > > unsigned _ExtInt(23) i; > > If such a type is introduced, would you prefer this type to exempt from > integer promotion? How would they pack in arrays, and how would it differ fron bitfields ? Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] long-term availability STM8...?
> Don't get me wrong, this risk is not specific to STM8 but exists for all > "old" microcontrollers, especially in these dynamic times. And most > other suppliers don't even offer such a program. Most do. Intel for example has a range of products with 15 year life time manufacturing support on certain parts (generally those aimed at industrial markets). NXP has a formal list of "long life" products with 10-15 year guarantees from launch. Ditto a lot of others. Not all of them bother telling 'little people' about it. If you order enough or you are a big government body like the military then you get to discuss such matters. For small volumes it's also getting easier and easier to get pin compatible generic logic parts using things like the Trenz GODIL devices that put a Spartan 3E and level shifters and glue into a device that fits a 40-40pin dip socket but overhangs a bit and people have now built retro-replacement devices like the vLA128 for a long defunct logic array that fits in the same space as the original. FPGA and soft logic implementations for most of the really old processors are available both free and commercially, I suspect we are now at the point many of the old DIP ones you could squash a low end ARM system on the DIP footprint and run it as software within the original power/space budget just as people replaced 555 timers with PICs. Bigger problem is that 74xx through hole parts seem to be slowly but surely disappearing. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Would it be useful to be able to call functions written for or compiled by other Z80 compilers?
On Fri, 16 Jul 2021 09:49:59 +0200 Philipp Klaus Krause wrote: > For the Z80, many different calling conventions exist. > Recently, SDCC introduced keywords __raisonance, __cosmic, __iar for the > stm8 port, that can be used to mark an individual function to use the > calling convention of the Raisonance, Cosmic or IAR compiler. > > For Z80, we already have __smallc, which was introduced to allow calling > functions originally written in assembler for Small-C. > > Would it be useful if z80 and related ports would support more such > conventions, e.g. for BDS C, Aztex C, IAR, Dynamic C, Hi-Tech, Cross C > or another C compiler for Z80/Z180/Rabbit? Do you plan to also support linking with object modules from those compilers ? If not I can't see a use case at all. Dynamic C is seriously warped so it's a pain to port stuff from that to an actual C compiler but if you cant cross-link it's no use anyway that I can see. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Changing the ABI for the STM8 port: BREAKS EXISTING CODE, is more efficient
> * When the --sdcccall option is not used: in trunk, the old convention > is the default, in the branch the new convention is the default. > * In trunk, the standard library is compiled for the old convnetion, in > the branch it is compiled for the new convention. > > If users are happy with the new ABI, these two differences will be > merged from the branch to trunk in the future. THIS WOULD BE A BREAKING > CHANGE, as hand-written asm code written for the old calling convention > would stop to work. Will the general -sdcccall option be remaining ? because I'm not going to be rewriting all the asm and the banking support for a new ABI in the near future so if not I'd have to just drop support for newer versions of SDCC from my code for the time being. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] More functions for bit manipulation (Rotation, population count, endianness, etc) in the standard libary?
On Sun, 3 Oct 2021 09:57:28 +0200 Philipp Klaus Krause wrote: > Dear SDCC users, > > would you consider it useful to have more functionality for bit > manipulation exposed as functions in the stadnard library. If yes, any > of the following (and if yes, with which interface?)? Anything else? > > * Endiannnes conversion for individual integers (e.g. big-endian to > native, native to little-endian, etc) via functions that convert from a > cahr array to the inetger or vice versa Right now Fuzix uses a bunch of longwinded defines with SDCC and they often generate poor code as SDCC doesn't appear to spot the opportunities to do things like load a long into four memory addresses in reverse order. Having the gcc __builtin_bswap16/32/.. functions wopuld be nice - and they seem to be turning into a sort of defacto standard. From those you can then generically produce the Linux like cpu_to/from_ and the BSD htons and friends given an endianness defines. If they are not builtins that resolve to constants at compile time then they are a lot less useful for me at least as I put them in initializations. > * Population count (i.e. the number of bits that are 1) of an integer I don't currently use __builtin_popcount*() or population counts. > * Rotation of integer types > * Count leading / trailing zeroes / ones __builtin_ffs/fls __builtin_ffz/flz are applicable to a pile of OS functionality, although for speed reasons very little Fuzix code uses them on 8bit systems. > * Single bit chek (i.e. check if an integer is a power of two, and if > yes, which one) Currently doing this with the usual algorithm explicity. > * Generic byte reverse for a block of memory Yes. Fuzix uses the existing 2 byte one from Posix (swab) in several places but having the __builtin_bswap*() from gcc would be useful for 4 byte swaps in a couple of spots. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] SDAS assembler doesn't support .define, etc. directives?
> linker situation. On the other hand, there might be an alternative: Use > assemblers and linkers from GNU binutils (I think this would make it > much easier to implement the link-time dead code elimination many users > requested). But that would also be some effort, add an extra dependency, > and GNU binutils doesn't support all architectures supported by sdas. > Still, it might be the better way in the long term. Not only that but the GNU tools frequently "support" something but it turns out that architecture was last touched 3 years ago, whoever maintained it has stopped and it becomes really hard to fix because many of the GNU tool interrnals are pretty gothic and not well documented. The biggest thing most of the other tool chains have is actually support for C pre-processor output as assembler input. That's actually also probably fairly easy to do as it just involves parsing a tiny number of lines in the form # number name flags (adding flags seems to be a GNU ism) the number is the source line number, the name is the source file name and the flags various extra info bits that don't really matter. They are there so that the other tools can output error messages giving the actual unprocessed source file and line number. If anyone is going to do any of this can I put in a plea to also allow the object files to be recognized if ending ".o". The weird, non-standard naming is the biggest single problem I hit because it breaks all the Make implied rules and the like - and if you want to support GNU tools you'll need to accept that ".o" can be an object file ending anyway 8) > Anyway, patches that merge current as into sdas would be welcome, > and so would be patches that improve support for using GNU binutils. On the Z80 side it would be nice to see the John Coffman table driven Z80/180/280 stuff merged but as that basically replaces the existing Z80/Z180 assembled with the much changed one it's probably more difficult. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] overlaying _INITIALIZED over _INITIALIZER sections
On Sun, 20 Feb 2022 15:15:40 +0300 Tony Pavlov via Sdcc-user wrote: > Hi, > > i have a question about SDLD. On systems where programs are > loaded inro RAM, say, MSX or ZX Spectrum or whatever else > computer, there is some sense in saving RAM by making > _INITIALIZED and _INITIALIZER section have the same base address. > Unfortunately, that is not very easy task, because you can not > put sections one after the other efficiently because of the unknown > sizes of sections which land before. for example: Short answer - use Z88DK instead. Z88DK has a main compiler which is a modified SDCC but it also has everything for developing on RAM based systems as well as support libraries for things like ZX Spectrum, and tools to compile into things like .tap files. > > .area _CODE > .area _INITIALIZER > .area _WHATEVER > > and then > > -b _CODE=0x100 -b_INITIALIZED=l__CODE+0x100 > > is not working because l__CODE is only known after that linking > phase. > > another solution adding a sommandline option into SDCC itself, > that force emission of initialized variables together with labels > into one single section. > > what do you think about this? any suggestions? It would be helpful I think. SDCC is a bit tied to ROM based systems. You can't tell it to produce only initialized sections, you can't force a specific segment to 0 (the linker instead treats 0 as 'wherever'), it can't do relocations, it can't do automatic banking and you can't even reliably force link order without using the linker separately and a .lnk file. I gave up trying to fix SDCC and instead just wrote some tools that take the SDCC binary output and rearrange them to taste. If you look in the Fuzix repository (github.com/EtchedPixels) there are a bunch of tools that parse the SDCC map file and then use it to do various things like move the initializer data to initialized, generate relocatable binaries etc, plus some simple patches and a modified linker that can generate banked binaries, as I use on things like Fuzix on the ZX Spectrum 128K and the Russian clones. For most things however I think you'll find Z88DK can do it out of the box. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Spurious Link Option
On Wed, 13 Jul 2022 14:35:31 +0100 William Brendling wrote: > I am using the following SDCC version: > > SDCC : > mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 > 4.2.0 #13081 (MINGW64) > published under GNU General Public License (GPL) > > I am compiling with the line: > > sdcc -mz80 --code-loc 0x8000 main.c > > The resulting "main.lk" file is: > > -mjwx > -i main.ihx > -b _CODE = 0x8000 > -b _DATA = 0x8000 > -k C:\Program Files\SDCC\bin\..\lib\z80 > -l z80 > C:\Program Files\SDCC\bin\..\lib\z80\crt0.rel > main.rel > > -e > > This contains the spurious line "-b _DATA = 0x8000". As a result the > data overlaps the code. > > Is there any way of preventing SDCC from emitting a "-b DATA" > directive so that the linker just packs the DATA section after the > CODE section in the order specified by the "crt0.s" file? Dont use sdcc to do the link but write your own link file. Note btw that SDCC doesn't support anything but ROM based content unless you fiddle with it - it's wedded to the idea that initialized variables are copied from ROM somewhere so if you are running from RAM you'll also need to massage the binary and stuff. The Z88DK fork of SDCC is often more useful for retrcomputing and RAM based setups. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Possible changes to inline assembler syntax
On Thu, 14 Jul 2022 12:58:07 +0200
Philipp Klaus Krause wrote:
> SDCC currently supports two forms of inline assembler:
>
> 1:
> __asm
> asm code here
> __endasm;
>
> and
>
> 2:
> __asm("asm code here");
>
> Form 1 requires some ugly hacks to avoid conflicts in the preprocessor.
> I wonder if we could drop those, and maybe even change the keyword in
> form 2 to __asm__.
>
> Does anyone rely on form 1 and would not want support for it dropped?
> Any opinions on the possible rename of form 2?
Fuzix relies on form 1 but at the moment I'm stuck with the older SDCC
anyway due to all the register and other changes.
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] What are the main (dis)advantages of SDCC vs. non-free compilers?
On Thu, 21 Jul 2022 14:06:42 +0200 Philipp Klaus Krause wrote: > Dear SDCC users, > > you have chosen SDCC over non-free alternatives. I'm a bit interested in > knowing the reasons. And also in knowing in which areas you think SDCC > is lacking compared to non-free alternatives. Also: do you use non-free > compilers for some of your projects for architectures supported by SDCC? > Knowing which architectures these (dis)advantages apply to would also be > helpful. I use it because I don't want to be dependent upon compilers I can't hack fix, or modify. Good bits - Code generation is best I've seen for Z80 (yes it's bad for some stuff but it's still beating the rest by a lot) - Actually maintained - Being open I could hack my own fork to support RAM based binaries well and also transparent code banking - Code quality is reasonable and it's possible to make changes and work on it a bit. Bad bits - Stability. Each release seems to fix 5 things and break 4 different ones which makes it harder to manage - Lack of proper support for RAM based binaries on Z80 - Doesn't follow any C compiler conventions about object file naming, not filling the current directory with trash files I don't want etc - Compile time peformance (although this has improved) - Doesn't know how to build relocatable binaries (but there are patches and way to deal with this plus forks like Z88DK) Some people will know I plan to drop SDCC for Fuzix eventually but to be clear that is solely because I intend to have a self-hosting compiler not because I dislike SDCC. ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] new sdcc calling conventions for z80/gbz80 together with __banked
On Thu, 4 Aug 2022 09:06:35 +0200 Philipp Klaus Krause wrote: > Am 29.05.22 um 21:44 schrieb Tony Pavlov via Sdcc-user: > > > > > another annoying thing is one byte hidden parameter for the bank number on > > the Z80 target. > > inc sp/dec sp everywhere, while on gbz80 two bytes are reserved - that is > > much faster! why > > not unify that? also, on systems like MSX you may want to save/restore more > > than one page > > and two bytes may be very useful here! > > > > > > Well, I'm personally not very familiar with all that banking stuff. I > try not to break it, but otherwise leave it to other sdcc devs (or wait > for patches from users). But since I'm not that familiar with it, I'm > reluctant to make changes that might be a problem for other users. You actually want the smarts in the linker not the compiler IMHO (especially on Z180 and R2K/R3K). On Z80 with the Fuzix patches for transparent banked support I use push af call foo pop af which has a cost but creates the needed consistent extra stack offset for all functions. The linker rewrites those 5 bytes into something else for a cross bank (or overlay..) function. That allows arbitrary calling between banks to work properly as you've got the 2 bytes needed. Typically it's something like call __bank1_2 ; from 1 to 2 .word foo You also have to rewrite function pointers for it to work properly so that any function pointer is turned into the address of a stub in common space that does the banked call needed. This is also needed for standards compliance so that all references to the address of the function give the same value. R2K/R3K is a bit different because the processor is designed to keep a rolling window of paged in code with most common space for data but apart from having extra hardware support the same basic logic applies along with rather more linker magic to pack functions so no function crosses an 8K boundary. It's something the official compiler does (did - it's basically dead software you have to run under emulators) but would be a big change to the very primitive linker SDCC relies upon. Whether explicit or automatic banking is the best option is another topic altogether and does depend a lot on use cases Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Why are my string constants being redundantly duplicated?
On Sat, 1 Oct 2022 12:47:51 +0100 Basil Hussain wrote: > I have come across a problem with SDCC for some reason including > constant string data twice inside compiled binaries. Move them out of the function and the problem goes away. It seems to be a bug but SDCC has behaved this way since forever. ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Interest in an r800 port to better support R800 and Z280?
On Sun, 23 Jul 2023 10:19:32 +0200 Philipp Klaus Krause wrote: > I wonder if SDCC users would be interested in an r800 port (and maybe > help a bit with the work). > This port would target the R800 (its instruction set is a superset of > the Z80 and subset of the Z280), and thus be useful to both R800 and > Z280 users. > > Feature request: https://sourceforge.net/p/sdcc/feature-requests/882/ > > The effort required would be substantially less than for a full z280 port. Some Z280 would be useful (the full Z280 assembler changes were already done but never merged with upstream it seems). If it's just the R800 mul and using ixl/ixh then it would have some use - and if it can be done without the multiply also for Z80 only code where they are illegals but always work. The big stuff in Z280 proper though is the stack relative and index relative word operations which doesn't seem much different to the existing paths for rabbit and ez80 ? Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Assembler variable overflow
> How do you check over/underflow in C without wasting memory? If your compiler is smart enough then for unsigned maths r = a + b; if (r < a) will be optimized nicely. I've not checked if sdcc knows that and will turn it into a carry check at least for uint8 and uint16. For signed maths there is not nice portable approach because signed maths overflow is undefined in C and indeed there are even processors where you get a maths exception for your trouble. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports
On Mon, 24 Jun 2024 11:25:54 +0200 Philipp Klaus Krause wrote: > Dear users of the z80 and related ports, > > we currently do have the --reserve-regs-iy option to make sdcc generate > code that does not use the register pair iy. But we do not by default > ship with a standard library compiled with --reserve-regs-iy. > > How useful would it be for users of z80-related ports if SDCC would ship > such a library for some ports? > Would such a library be useful to you? If yes, for which port? I have no use for it. The platform I need to reserve registers on for NMI is the Sinclair ZX81 and it needs IX reserved and to an extent IY although that one can be dealt with unlike IX It's a confusing mess in Z88DK's use of this because Z88DK started with a hack that avoids using IY and turns IX into IY in the assembler so reserves IY but actually really reserves IX because it modifies all your assembler for you. I would guess the Z88DK register mangling mayhem for the ZX81 is the only general use case. There are a few CP/M BIOSes with bugs that corrupt IX or IY on some calls but those are handled by just pushing registers around CP/M BDOS calls and taking the precautionary position that enough CP/M BIOS writers are idiots to justify it. Alan ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
