Re: [Sdcc-user] Z80 code in RAM
>I assumed that he only wants some small special part of his code to execute from RAM. In that case he could use C memcpy() to copy, but would have to place the special code in a different segment. Yes I think he has some self-modifying code that needs to be in a data section so that it is copied into RAM at startup. I hate to advertise on another list but it’s probably not so bad since we’re trying hard to get sdcc to play well with z88dk and it’s pretty much done now. If you're willing to use sdcc through z88dk you can do what you want. There is a self-modifying code section defined so that the crt will copy your code into RAM automatically at startup. This is how it is done for sdcc in z88dk: ;; FILE: myasm.asm SECTION smc_user ;; assign to self modifying code section PUBLIC _myfunction ;; export function name _myfunction: ; do stuff ret In your C code you can generate a reference to your function: extern int myfunction(void); The compile line simply adds both files: zcc main.c myasm.asm All the funnies that Alan spoke about are removed, ROM and RAM models are accommodated and you can compress your data section if stored in ROM. The best part is the C lib is more complete and it’s all written in assembler. If you’d like to give it a try let me know.-- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 code in RAM
Let’s try that one more time seeing as that didn’t work... >I assumed that he only wants some small special part of his code to execute from RAM. In that case he could use C memcpy() to copy, but would have to place the special code in a different segment. Yes I think he has some self-modifying code that needs to be in a data section so that it is copied into RAM at startup. I hate to advertise on another list but it’s probably not so bad since we’re trying hard to get sdcc to play well with z88dk and it’s pretty much done now. If you're willing to use sdcc through z88dk you can do what you want. There is a self-modifying code section defined so that the crt will copy your code into RAM automatically at startup. This is how it is done for sdcc in z88dk: ;; FILE: myasm.asm SECTION smc_user ;; assign to self modifying code section PUBLIC _myfunction ;; export function name _myfunction: ; do stuff ret In your C code you can generate a reference to your function: extern int myfunction(void); The compile line simply adds both files: zcc main.c myasm.asm All the funnies that Alan spoke about are removed, ROM and RAM models are accommodated and you can compress your data section if stored in ROM. The best part is the C lib is more complete and it’s all written in assembler. If you’d like to give it a try let me know.-- ___ 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
>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. There are many examples of C programs in the wild that use floating point for convenience, here are some that have been successfully compiled using sdcc for z80 targets but using a 3rd party z80 library: One of the world’s smallest chess programs. Shockingly it uses floating point: http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/umchess.c?revision=1.2&view=markup The familiar startrek program from the 70s, directly translated from Basic: http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/startrek.c?revision=1.2&view=markup Whetstone synthetic floating point benchmark. Well this one doesn’t really count as an application example: http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/whetstone.c?revision=1.4&view=markup Using something for convenience is fine as long as the implementation is affordable. This is the sticking point with sdcc’s current fp package -- it’s really large to the point that it can become unusable in non-trivial programs. For the whetstone example, a native sdcc build eliminating i/o comes to 14k in size in comparison to a build using sdcc and the 3rd party library coming to 6k. That’s an extra 8k cost for using the native float package in sdcc and it comes down to the float package being written in C in comparison to the third party library’s implementation in assembler. Because of the size difference, it’s unlikely that the startrek example above could be compiled for many z80 targets using native sdcc due to memory size limitations. I don’t think changing to a smaller float type will reduce the code cost and I think that’s where a fundamental improvement in sdcc could be found. You will speed it up by n times because loops will be shorter but I’d argue that's not the central goal when using fp on a z80. Our needs are a little bit different. We have several floating point libraries that are selected between on the compile line. You’re choosing between two different z80 floating point packages, both of which are 48-bit because, as it turns out, 48-bit is the maximum convenient size for floats on a z80. Then it’s also possible to use a native floating point implementation that may be present as system software on a specific target (zx spectrum, cpc, msx, and so on). Most of these are 32-bit with small variations in in-memory format and register assignments. Sdcc only understands a single 32-bit floating point format so the libraries have to adapt by performing runtime conversions between sdcc’s fp format and the format used by whatever math package is selected on the compile line. A new short float format I don't think is going to solve any problems on any microcontroller that doesn’t have a corresponding native hardware implementation. The standard is simply trying to accommodate graphics processors which do define these half float formats. However, a short fixed point format would probably be well served on micros like the z80. What I am getting at is, ideally, we’d be able to tell the compiler what the floating point format is at compile time so that these runtime conversions don’t have to be made. That might be pie in the sky; another alternative is to define generic float operations on short floats, floats and/or doubles with the compiler assuming each type is x,y,z bits in width. It is then the responsibility of the library to assign meaning to the bits and to implement the defined float interface. This would solve our runtime conversion problem and it would allow us to define short floats to actually be fixed point where advantage could be gained from that without taking away from the possibility of other math libraries defining short floats differently such as ieee.-- 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! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights
Re: [Sdcc-user] A floating-point type cheaper than float
>I don't think any of us disagree with the convenience thing. But >is anyone actually using 16 bit floats for their apps or projects? >The biggest problem is the 11 bit precision -- 8 bit MCUs probably >calculate using 16 bits of precision and then unpack-pack into the >half float format. Right now I am really really interested in >seeing a real life 8-bit MCU program that uses 16 bit floats, or >something very close in spirit... I don't disagree with you. I don't think there is any significant advantage to having a short float in addition to a regular 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. Convenience is important as we all agree and I also agree with Kusta that there are applications where a large dynamic range is needed such that fixed point would not be most appropriate. However I do see a need for a fast fixed point type and my point was you may be able to design at the compiler end to allow the library to decide that a short float might actually be implemented as fixed point. With the right design the burden of float definition is moved from the compiler to the library and when this is done you can be very flexible about what the float formats actually are. There is a sticking point about how float constants in C code should be translated to its binary representation (how does the compiler know when the float format is defined in the library?) There is another advantage in this for sdcc in particular since it aims to support a variety of MCUs. The most natural floating point format for a specific MCU is going to be shaped by number of registers, register widths and instruction set. On the z80, the largest natural float size is 48-bits. The reason is two floating point operands can be held in registers BCDEHL and BCDEHL' in the exx set. Few(er) memory operations are required to implement the math functions and the float package can be re-entrant because no static memory is used to hold parameters. Obviously such a format is not going to be a universal fit for all MCUs so this ability to let the library decide also allows efficient implementations with variable characteristics for different MCUs. >> [snip] >> One of the world’s smallest chess programs. Shockingly it uses >> floating point: >> http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/umchess.c?revision=1.2&view=markup >Ummm... where are the floating point declarations? Have a look at line 125. There are no float declarations but there is floating point math. The program is written to be small in the source code sense so there's probably no reason to use floating point other than to reduce the number of characters typed. >Very nice, if only someone had a metric truckload of time to >expend on it. You'd be surprised what accumulates over a few decades for some of these legacy processors. The z80 in particular has a large body of C-related libraries written in assembly language and still many active hobbyists contributing. What I am suggesting would take a lot of work in the library end, enough work that for most MCUs it would never be taken advantage of. But for the z80, do it, and eventually it will come. >I don't think it would be as >easy as defining widths, and maintaining such things is something >dedicated retrocomputing developers need to do, IMHO we should not >burden folks like the SDCC devs with a ton of legacy requirements. I'm not suggesting SDCC do it. There's a reason why its C library is written in C -- you instantly have portable code that presents the same API to every target. The cost is larger and slower code than alternative specialized libraries written in assembly language that might be implemented for specific MCUs. It shouldn't be SDCC's job to maintain such disparate libraries. That would be the job of the people maintaining those specialized libraries.-- 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
>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. 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. SDCC tries to be standards compliant so I think it would prefer to define these float formats to have the widths expected of them -- short float might be 16-bit, float 32-bit and double 64-bit. On some MCUs there might be an intermediate size that is efficiently implemented like 48-bit for the z80. Since 64-bit doubles are going to be painful in generated code I think I would agree with Philip that double perhaps could be shortened to take advantage of that on those MCUs. Maybe long double could be used to mean at least 64-bits. If SDCC itself defines these types short float, float, double to be 16-bit wide, 32-bit wide, 48-(64-)bit wide respectively and it defines a float interface using those widths for each float type, then it's possible to allow the library to assign meaning to the bits and therefore implement whatever float format it wants to, IEEE or not. This is almost how we do things for SDCC now. For the z80, SDCC does define a float interface via its compiler primitives. Its float type is 32 bits wide. We write the code implementing these primitives in the specific math library linked against and that math library also defines new functions as required by math.h. Because the float type is known to be 32-bits, the register interface for all math functions is known. So far there is nothing that says what the format of the 32-bit float is. The one thing that stops us from using whatever format we want is that SDCC itself must encode float constants seen in C source and it does so assuming the float format defined by its own float package. That means we have to insert float format translation code between the compiler and float package, so every SDCC float primitive and math.h function has a call at the beginning to convert the SDCC format to the math package format and every returned float value sees a conversion from the math package format to the SDCC format. *IF* SDCC could be instructed to encode float constants in a way defined at compile time that is consistent with the float package linked against, we can get rid of all the float format conversion and SDCC's float type is now entirely defined by the math library rather than the compiler, except for bit width. This is what I am offering up for consideration. Specifically for the z80, as mentioned before, we have two standalone float packages that are 48-bit. For SDCC we have one of these packages available that is selected on the compile line when "-lm" appears. Because SDCC only knows about 32-bit floats, there is conversion code that translates from SDCC's 32-bit format to the 48-bit format and vice versa. So although math is done in 48-bits, SDCC only sees 32-bits of it. If SDCC adopts a 48-bit double, we could keep the precision. If SDCC can be told to encode double constants using this library's float format at compile time, we can eliminate the runtime conversion code. We will also have adapters for system-specific float libraries. The zx spectrum as you mentioned has a 32-bit float type. We will do it the same way by writing the SDCC float primitives to use the zx's rom calculator. Then the math.h functions will also be written to use the rom calculator. This set of float functions may be selected on the compile line with "-lmzx". Because the zx's float format does not align with SDCC's built in format, we have to insert conversion code into these functions. Again, if SDCC can be told to encode float constants using the zx format at compile time, we can eliminate that conversion code. Likewise for the cpc and msx, we can generate libraries linked against on the compile line to use their float implementation in rom using, eg, "-lmcpc" and "-lmsx1". 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. The short float type may be 16-bit. We might use that to offer a 16-bit fixed point type chosen with "-
Re: [Sdcc-user] New user / header files / optimisations STM8
>However, just a few days ago we discussed >various floating point formats and one of them >was to leave the actual computations to the FP >library, which would make it hard for the compiler >to optimise these as it could not call those functions >at compile time. >This is pretty trivial to optimize at compile time >as long as everything is IEEE FP but if the run time >libraries are not 100% compatible we have subtle issues. I don't think leaving the stored float format to the library interferes with this sort of optimization. The compiler can still do computations using the max precision fp type it has; the last step for the compiler would be communicating this result to an external function supplied by the library authors to generate a stream of bytes representing the number in the proprietary format.-- 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
> Ah, yes. Level-triggered interrupts. So I guess I'll just drop support for 2) for the z80 and z180 backends. We can keep it for the tlcs90, r2k and r3ka, which use edge-triggered interrupts. Anyone know about gbz80? No number 2 is correct for the z80 in im2 mode with hardware acknowledge and hardware interrupt priority. Old computers like msx did not take advantage of im2 mode so they tended to have simple interrupt schemes involving polling and level interrupts. >1) non-interruptible isr (can be interrupted by nmi only): >void i1(void) __interrupt push ... pop ei reti >2) interruptible isr (can be interrupted by any interupt) >void i2(void) __critical __interrupt(0) ei push ... pop reti This is suitable for daisy chain im2 mode where interrupt priority and acknowledge is done in hardware. All of Zilog's peripherals conform to this but quite often implementations do not take advantage of it. >3) nmi handler (can be interrupted by nmi only) >void i3(void) __critical __interrupt push .. pop retn-- 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 -- 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
[Sdcc-user] VS2010 Source Compatibility?
Is sdcc still trying to maintain VS2010 source compatibility? A lot of the
recent commits are incompatible with VS2010, all having to do with mixing
declarations inside code blocks which VS2010 does not support. A recent
example:
int csdOfVal (int *topbit, int *nonzero, unsigned long long *csd_add, unsigned
long long *csd_sub, value *val)
{
*topbit = 0;
*nonzero = 0;
*csd_add = 0;
*csd_sub = 0;
unsigned long long binary = ullFromVal (val);
bool gamma, theta, a;
int bit, next;
...
This must be rearranged so that executable code occurs after the variable
declarations. In short, C89.
int csdOfVal (int *topbit, int *nonzero, unsigned long long *csd_add, unsigned
long long *csd_sub, value *val)
{
unsigned long long binary;
bool gamma, theta, a;
int bit, next;
*topbit = 0;
*nonzero = 0;
*csd_add = 0;
*csd_sub = 0;
binary = ullFromVal (val);
There are about a dozen of these sorts of fixes currently so I thought I'd
better say something before it turns into hundreds.
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] z80 binary sizes increasing by 25%
Sometime after #9676 and up to and including #9682, I am seeing an increase in z80 binary sizes of 25% in some compiles. It seems to be connected to increase spill to the stack and higher use of index registers in accessing stack variables. I will try to look closer to nail down what it is but I am wondering if anyone else is seeing this. I can give a link to before and after list files showing asm generated by #9676 vs #9692 for a particular case of a binary increasing from 39k to 51k. https://drive.google.com/file/d/0B6XhJJ33xpOWLTJRTkgxRzNXQ2s/view?usp=sharing -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] z80 binary sizes increasing by 25%
>There was a bug in the fix for bug #2467. I fixed it in rev #9705. can >you check if that solves the code size regression for you? Yes things seem to be back to normal. Code size for that example is at 39088 bytes in #9707 vs 39124 in #9767 and > 50k in between. -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
> * Install LLVM 3.8 (e.g. using apt-get on Debian). > * Get my cfe fork (https://github.com/spth/clang) and build it (e.g. > mkdir build; cmake ..; make) > * Get the cbe fork (https://github.com/Ace17/llvm-cbe) and build it (see > instructions in README.md) Is it the master branch if the cfe fork that I should be using? I'm getting a number of errors when compiling with llvm-3.8.0. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
>>> instructions in README.md)
>>
>> Is it the master branch if the cfe fork that I should be using?
>
>master for cfe, standalone for cbe.
>
>> I’m
>> getting a number of errors when compiling with llvm-3.8.0.
>>
>
>I'm using LLVM 3.8.1, and the cfe fork is based on the cfe from 3.8.1.
>But I don't know if that is the cause of your problems.
LLVM 3.8.1 isn't getting any further. The CFE source code doesn't look
compatible with LLVM 3.8.1.
The first source code error:
llvm-3.8.1/tools/clang/utils/TableGen/ClangAttrEmitter.cpp: (line 1220)
ArrayRef> Bases = Search->getSuperClasses();
"Search" is a lllvm::Record*
llvm-3.8.1/include/llvm/TableGen/Record.h/Record.h: (line 1230)
ArrayRef Record::getSuperClasses() const { return SuperClasses; }
The CFE is expecting an incompatible return value from that function. This is
definitely an error.
There were also a few errors during cmake which I ignored or tried a minor
workaround to get further but one of them complained about a missing component
"Coverage" in LLVM which may also indicate incompatible LLVM version.
Is 3.8.1 the only version of LLVM installed on your system? I am compiling the
whole works from source code but I got similar errors when I installed
LLVM-3.8.0 rather than compiled it. I think I will look into the LLVM releases
and see if there is one of them that defines Record::getSuperClasses() in the
way expected by the CFE. And if that doesn't work, go back to installing LLVM
and compiling the CFE separately.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
> On my Debian GNU/Linux amd64 system I currently have the following > llvm-related packages installed: > > clang-3.8 > clang-3.8-doc > libclang-common-3.8-dev > libclang1-3.6 > libclang1-3.8 > libllvm3.6v5 > libllvm3.7 > libllvm3.7:i386 > libllvm3.8 > libllvm3.8:i386 > llvm-3.8 > llvm-3.8-dev > llvm-3.8-doc > llvm-3.8-runtime > > All the 3.8 stuff is 3.8.1 There are no other LLVM bits installed (I run > the cfe fork and the cbe from where I built them, didn't install them). The cfe source code is definitely in a mixed up state. Some of the source code requires definitions from 3.9.1 and some from 3.8.1 so the author(s) have probably been compiling against something in between. I don't think it's possible to build alongside llvm which is what I was trying to do. I will try again to build against a separately installed llvm 3.8.1 as you did. I think maybe the linker would not catch some of the errors I saw while building from 3.8.1 source. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
On 07.11.2016 20:12, Philipp Klaus Krause wrote: > On 03.11.2016 12:14, Philipp Klaus Krause wrote: >> On 03.11.2016 00:56, alvin albrecht wrote: >>> >>>> * Install LLVM 3.8 (e.g. using apt-get on Debian). > release_38 for cfe. Much better, everything compiles fine. The llvm-cbe seems to be geared toward compiling for gcc and msvc and defines a number of macros in the course of its code generation, some of which I had to define to eliminate them from the source. #define __attribute__(x)= #define __builtin_unreachable(x)= #define static inline=inline This last one was at your suggestion to remove the extra unused static inline functions that llvm was producing and this did work. This is not an exhaustive list; I also ran into a "__UNALIGNED_LOAD__()" which is a struct copy. I hand edited those to memcpy but this is less than ideal as some of those struct copies could probably be eliminated. There are probably more macros waiting to appear. The compile sequence I am using is feeding to clang plain header files (without fastcall, callee, preserves_regs attributes) and then taking the resulting .cbe.c from llvm-cbe and feeding that into sdcc with sdcc header files enabled (ie fastcall, callee, preserves_regs are re-instated). These attributes make quite a big difference to compiled code quality so this is the way it has to be done to give the cfe/llvm a chance to generate competitive code. What's happening is the cfe is expanding the header files, the llvm-cbe only sees the prototypes and it outputs prototypes only in the .cbe.c code. What I would want is for the #include headers to remain intact in the .cbe.c file and llvm-cbe not to generate any prototypes. I hand edited the .cbe.c files to remove the prototypes and added the #includes back before the sdcc compile. The largest working test that I tried using the above process was eliza.c ( http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/eliza.c?revision=1.7&content-type=text%2Fplain ). It was a painless process with some manual intervention. Because the llvm-cbe for some reason wraps types in structures, I did have to fix some incompatible pointer type errors from sdcc. In particular, the llvm-cbe definition of FILE* as a struct was incompatible with the library's definition of FILE* so I had to cast some instances of stdin to "(void *)stdin". The cfe compile came out to 500 bytes larger than the sdcc compile, about 50% larger in the c compiler generated portion. The wrapped structures led to a lot more temporary variables being generated. sdcc already generates near ideal code for eliza.c so I tried something larger that is not ideally compiled by sdcc: a lisp interpretter clisp.c ( http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/clisp.c?revision=1.7&content-type=text%2Fplain ). The same sort of manual interventions were applied but I ran into a more difficult problem. llvm-cbe began wrapping some types into structures as pairs. So I ended up with structures containing two 32-bit numbers in a handful of places that made compiling difficult to achieve so I wasn't successful. In both cases I was running opt on the .ll before handing to llvm-cbe. I'm not sure if that made things worse or not because more of those wrapped structures appeared. Anyway it's a start but there's still much to do! -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
>> llvm-cbe began wrapping some types into >> structures as pairs. > >Did this happen for anything other than arrays? LLVM arrays semantics >are different from C (where arrays sometimes decay to pointers, while >structs don't). Keep in mind that the cbe also needs to be able to >compile LLVM code to C that came from other sources than the cfe. The fault was entirely in opt. In the clisp.c example, opt combined some data into pairs called vectors and since clisp is using a lot of 32-bit types that resulted in structures with two 32-bit pairs in them. I took out the opt step to avoid this and retried the compiles. The vectors went away and the results were better without the opt step. I put together a small zip so you can see some of the results: https://drive.google.com/file/d/0B6XhJJ33xpOWYWF5ZksycDVJSWM/view?usp=sharing == source code: eliza.c sdcc compile to asm: eliza.c.asm (max optimization) link to binary: eliza_CODE.bin clang compile to .ll: eliza.c.ll (-fnosigned-char --target=sdcc-z80 -S -emit-llvm -w, include search paths added) llvm-cbe compile to .cbe.c: eliza.cbe.c (-O2 -disable-partial-libcall-inlining, tools I am using define required macros, hand edited to change "static inline" to "inline" & restore headers for sdcc compile step) sdcc compile to asm: eliza.cbe.c.asm (max optimization) link to binary: eliza-cbe_CODE.bin The C compiler generated portion of the binary was 927 bytes for the regular sdcc compile and 1210 bytes for the clang compile. That's a lot closer than when opt was used. If you look at the generated asm, the size difference mainly comes from the use of a lot more temporaries on the stack. == source code: clisp.c sdcc compile to asm: clisp.c.asm link to binary: clisp_CODE.bin clang compile to .ll: clisp.c.ll llvm-cbe compile to .cbe.c: clisp.cbe.c (same manual edits as above) sdcc compile to asm: clisp.cbe.c.asm (max optimization) link to binary: clisp-cbe_CODE.bin The C compiler generated portion of the binary was 11466 bytes for the regular sdcc compile and 12853 bytes for the clang compile, which is quite close. == So far the cfe/cbe seems capable of compiling without much manual intervention. I'm a little afraid to try examples with floats in them but if you'd like me to try more non-trivial test programs let me know. When I spend more time on this the first thing I will be looking at is trying to automate the manual steps I am taking to complete compiles. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers
>always optimal. Still, we might benefit from some of the optimizations. >Have you tried calling opt with vectorizations disabled? I tried quickly this morning with vectorization disabled on opt and that solved the problem. But I ran into another - sdcc ran out of memory. It gets up to 2GB memory use and then is killed. I'm running on a windows machine so maybe I'll have to look at some of the compile switches to get over that limit but it appears there are some memory leak issues that don't cause trouble except in the large functions that llvm is generating. I'll make a source code file available later today after it's patched up with prototypes if you want to have a look. -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Peephole rules
>I've loocked at this file (as I mentioned earlier). Some moments push me to
>ask questions. There are parameters like
>
>notUsed('a'),
>notSame(%2 'push' 'pop'),
>notSame(%1 'xl' 'xh' 'yl' 'yh'),
>immdInRange(0 255 '+' %1 %2 %9),
>labelIsUncondJump(),
>labelRefCountChange
>and many others. i can look at examples and make my own like a monkey, but
>it's not best pra>ctice.
>Tried too lokk at sources of sdcc, but my sw skill isn't enough to understand
>code.
>And second. Some params of peep riules are numbered in series like %1, %2, %3
>etc,
>and some like %1, %5, %9. Why is it so?
What I found useful is to examine line ~1409 in
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/src/SDCCpeeph.c#l1409
(static const struct ftab). This structure defines all the conditions that can
be placed on peephole rules. Their implementation is just above that
structure. This is what I wish I had known about when I first started making
my own peephole rules.
You can use the existing peephole set for examples of how to use these
qualifiers.
The %n are text strings. Inside the peephole rules they represent strings
found in the source code. The numbers are only identifiers and are not
important.
The description of peepholer posted by R0b0t1 describes simple peepholers.
Sdcc's is a little more sophisticated.
--
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] Change between 9880 and 9889 In Peephole Application?
I’m seeing some odd behaviour in a change from 9880 to 9889 where some peephole rules are applied while others are not for user supplied peephole rules on a z80 target. The sdcc invoke uses the form: “--no-peep --peep-file peep.def”. Some rules are applied and others are not. The results we see are compiled binaries that are several kb larger. Can anyone think of something specific in there that might cause such behaviour? I’m still investigating so if I find it I will write back. -- 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] Change between 9880 and 9889 In Peephole Application?
Of course I found the problem in the very next thing I checked. The patch applied for https://sourceforge.net/p/sdcc/bugs/2600/ is incorrect and I will file there shortly. -- 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] Can't figure out how to write interrupt handlers for Z80 using SDCC
> but can't figure out how to use the above example crt0.s file with SDCC for a > Z80 target. Using the --use-crt switch doesn't seem to work. > unknown compiler option '--use-crt=crt0.s' ignored Have a look here for an example of using a custom crt.s: https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/dhrystone21/sdcc/verify Read Winmake.bat to see how the program is compiled. -- 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] sdcc compile issues with vs2105
I have a couple of compile issues using vs2015 with the current version 10024.
(1)
In sdcc/src/SDCCralloc.hpp line 618, the compiler complains that there is an
attempt to use deleted operator=.
Line 591 gives the option to use alternative code and if I set the IF to 0, the
compile is fine.
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xutility(458):
error C2280: 'assignments_introduce_instruction::inserter_t
&assignments_introduce_instruction::inserter_t::operator =(const
assignments_introduce_instruction::inserter_t &)': attempting to reference a
deleted function
2> C:\Projects\z80\z88dk\zsdcc\sdcc\src\SDCCralloc.hpp(618): note: compiler has
generated 'assignments_introduce_instruction::inserter_t::operator =' here
2> C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\algorithm(3211): note: see reference to function template
instantiation '_Iter &std::_Rechecked<_OutIt,_OutIt>(_Iter &,_UIter)' being
compiled
(2)
In sdcc/src/hc08/ralloc2.cc the compile is warning about a possible assignment
error on line 554:
This looks legit and the == is likely meant to be =.
{
iCode *ifx;
if (ifx = ifxForOp (IC_RESULT (ic), ic))
{
OP_SYMBOL (IC_RESULT (ic))->for_newralloc = false;
OP_SYMBOL (IC_RESULT (ic))->regType == REG_CND; /// < HERE
ifx->generated = true;
}
}
--
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
