>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 cop
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-modify
>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
>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. Righ
>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 SD
>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 optimiz
> 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
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 *
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 b
>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.
---
> * 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 for
>>> 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 d
> 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
>
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 compile
>> 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
>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 me
>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 c
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
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 o
> 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/
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:
21 matches
Mail list logo
