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 process
> 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
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
> 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
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'
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
> >
> 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
>
> > 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. Bu
> 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?
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
>
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 f
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 corrupti
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
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 loo
> 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 ca
> 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 th
> 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
> __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 t
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?
> *
> 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 tas
> > 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 behvi
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
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
> 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 i
> 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 f
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
> 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 r
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 rout
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 ye
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 `#p
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` an
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
--
__
> 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
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 p
> 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
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 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)
> 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
> 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
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 hav
> 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 repo
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 s
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
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 on
> * 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 me
> * 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
o
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
> &
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"
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
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
> 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
w
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, c
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 w
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
___
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;
> } __attribut
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 8k
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).
> > 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 tha
> 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 targe
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 gen
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 INITIALI
> 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
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
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
> 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 c
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 Ra
> * 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
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?
>
> 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
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
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 Gene
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
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 u
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 -
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 fore
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 bo
> 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 sign
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 wi
78 matches
Mail list logo
