Activity for Job Bolle
-
Job Bolle posted a comment on ticket #3471
The regression test no longer fails. (It's interesting that the fastest and smallest result is for MAPN=1024.) r13744: MAPN=1024 Summary for 'ucz80': 0 failures, 3 tests, 1 test cases, 1156 bytes, 23058 ticks MAPN=2048 Summary for 'ucz80': 0 failures, 3 tests, 1 test cases, 1157 bytes, 23075 ticks MAPN=4096 Summary for 'ucz80': 0 failures, 3 tests, 1 test cases, 1159 bytes, 23083 ticks MAPN=8192 Summary for 'ucz80': 0 failures, 3 tests, 1 test cases, 1158 bytes, 23071 ticks MAPN=16384 Summary for...
-
peep rule 174a now has the notSame(%1 'ix' 'iy') and notSame(%2 'ix' 'iy') restrictions twice.
-
The regression test for this bug fails (for me) without treedec with --max-allocs-per-node between 38142 and 170117.
-
... additionally, this replacement is not an optimization: ld iy, #0x0000 ; 4B, 14T ld iyh, b ; 2B, 8T ld iyl, c ; 2B, 8T It is not smaller, and it takes 2 more cycles.
-
moduschar for sm83
-
Example to reproduce: sdcc -mz80 --max-allocs-per-node 50000 -c device/lib/_fsadd.c _fsadd.asm:512: Error: <a> Invalid Addressing Mode. _fsadd.asm:513: Error: <a> Invalid Addressing Mode. removing _fsadd.rel 509: jr 00142$ 510: 00141$: 511: ld bc, #0x0000 512: ld iyh, b 513: ld iyl, c 514: 00142$: 515: ld e, -9 (ix) 516: ld a, -8 (ix)
-
The test for unsignedness of left could be done on the original left This gets rid of the negativity test and the conditional addition: --- a/src/SDCCicode.c +++ b/src/SDCCicode.c @@ -2256,6 +2256,7 @@ geniCodeDivision (operand *left, operand *right, RESULT_TYPE resultType, bool pt { iCode *ic; int p2 = 0; + bool left_unsigned = IS_UNSIGNED (getSpec (operandType (left))); sym_link *resType = usualBinaryConversions (&left, &right, resultType, '/'); sym_link *rtype = operandType (right); sym_link *retype...
-
geniCodeDivision() can do a simple right shift if left is unsigned and right is a power of two, but usualBinaryConversions() makes left signed if right is signed, as it casts both operands to the result type. The test for unsignedness of left could be done on the original left before it gets cast by usualBinaryConversions.
-
[z80] disallowed undocumented instructions
-
Good evening, I am trying to implement rtrackUpdate() for Z80. (I will probably have questions about this later...) While testing, I came across a case of dead code being generated. I made it so that a conditional jump not taken adds new knowledge about the CPU state. In this case, the new knowledge (bit 7 of D is set) conflicts with existing knowledge (D is zero), which I assumed indicated an error on my part, but it turns out that it indicated dead code. The following C code: unsigned char *buf;...
-
Good evening, I am trying to implement rtrackUpdate() for Z80. (I will probably have questions about this later...) While testing, I came across a case of dead code being generated. I made it so that a conditional jump not taken adds new knowledge about the CPU state. In this case, the new knowledge (bit 7 of D is set) conflicts with existing knowledge (D is zero), which I assumed indicated an error on my part, but it turns out that it indicated dead code. The following C code: unsigned char *buf;...
-
I'm a bit worried about dst[0] <= 'e', For both src and dst, this test is already only performed if isReg() is true. isReg() is only true for 'a' 'b' 'c' 'd' 'e' 'h' 'l', so <= 'e' excludes 'h' and 'l'. Similarly, isUReg() is only true for 'ixh' 'ixl' 'iyh' 'iyl', so src[1] == dst[1] is true if both uregs have the same letter in the middle, i.e. both are part of ix or both are part of iy.
-
Is HAS_IYL_INST the correct test, or should it be options.allow_undoc_inst? Do you prefer TRUE/FALSE or true/false in .c sources? --- a/peep.c +++ b/peep.c @@ -1217,6 +1217,28 @@ z80canAssign (const char *op1, const char *op2, const char *exotic) (!strcmp(dst, "ix") || !strcmp(dst, "iy")) && !strcmp(src, "hl"))) return true; + if (HAS_IYL_INST) + { + // Can load Uregisters into abcde + if (isUReg(src) && isReg(dst) && dst[0] <= 'e') + return TRUE; + + if (isUReg(dst)) + { + // Can load immediate...
-
You should get rid of the comma after notInJumpTable Otherwise it gives the following error: could not find named function "notInJumpTable," in peephole function table I guess the comma is never necessary but doesn't hurt after a close-parenthesis..
-
This error goes away with --no-peep It also goes away by moving labelRefCountChange after notInJumpTable in peep rule 85a I suppose labelRefCountChange should always be after any other restrictions that may make the rule not happen. --- a/peeph.def +++ b/peeph.def @@ -1178,7 +1178,7 @@ replace restart { } by { ; common peephole 85a eliminated jump. %1: -} if labelRefCountChange(%1 -1), notInJumpTable +} if notInJumpTable labelRefCountChange(%1 -1) replace restart { jp %1 @@ -1188,7 +1188,7 @@ replace...
-
The peephole rule restriction canAssign() returns false when one of the operands is ixh, ixl, iyh, iyl. isReg() is only true for a, b, c, d, e, h, l. I tested with this: --- a/peep.c +++ b/peep.c @@ -1175,9 +1175,22 @@ z80canAssign (const char *op1, const char *op2, const char *exotic) dst = op1; src = op2; - // 8-bit regs can be assigned to each other directly. - if(isReg(dst) && isReg(src)) - return TRUE; + if (HAS_IYL_INST) + { + // 8-bit (U)regs can be assigned to each other directly. + if((isReg(dst)...
-
It is normal behavior. So the pointer to the string becomes a pointer to a pointer to the string. No, it is just a pointer to the string. Unless you argue that every variable is a pointer because it has an address in memory: const int some_int = 0x1234; results in this: _some_int: .dw #0x1234 "For the int some_int, the compiler allocates 2 bytes in RAM which store the value of the int. The label _some_int points to this space in RAM. So the int becomes a pointer to the int." (See how this doesn't...
-
Looking into it... Hi Felix, You fixed it in [r13705]. I was trying to figure out what it would take for me to build 13690. After a bunch of trial and error I got it to build by passing -DHAVE_SYS_RESOURCE_H -DHAVE_STRUCT_TMS -DHAVE_CLOCK_T -DHAVE_STRSIGNAL to make. Then I tried whether that would build HEAD (13709) which it did. Then I wanted to write up a nice report, detailing which errors I got and which define would get rid of which errors and what the next errors would be, etc... In order to...
-
It looks very similar to [bugs:#3473], It is exactly the same bug as 3473. Sorry for the clutter / distraction. I am on 13687, but yes, SDCC reports 4.2.8 #13684 (Mac OS X x86_64) At the moment I can not build 13690 and later, but I applied the changes from revision 13691, and now the test no longer fails and stepping through uCsim, those IYH/IYL related codes affect the correct parts of the correct registers in the correct way. IX= 0xff7e [IX]= fa 250 . IY= 0xd4ff [IY]= 00 0 . AF= 0xffa8 [AF]= 00...
-
It looks very similar to [bugs:#3473], It is exactly the same bug as 3474. Sorry for the clutter / distraction. I am on 13687, but yes, SDCC reports 4.2.8 #13684 (Mac OS X x86_64) At the moment I can not build 13690 and later, but I applied the changes from revision 13691, and now the test no longer fails and stepping through uCsim, those IYH/IYL related codes affect the correct parts of the correct registers in the correct way. IX= 0xff7e [IX]= fa 250 . IY= 0xd4ff [IY]= 00 0 . AF= 0xffa8 [AF]= 00...
-
It looks very similar to [bugs:#3473], It is exactly the same bug as 2373. Sorry for the clutter / distraction. I am on 13687, but yes, SDCC reports 4.2.8 #13684 (Mac OS X x86_64) At the moment I can not build 13690 and later, but I applied the changes from revision 13691, and now the test no longer fails and stepping through uCsim, those IYH/IYL related codes affect the correct parts of the correct registers in the correct way. IX= 0xff7e [IX]= fa 250 . IY= 0xd4ff [IY]= 00 0 . AF= 0xffa8 [AF]= 00...
-
(This is not a request for help. Just FYI..) I ran Z80-undoc regression tests to make sure my custom peephole rules don't break things. One of the regression tests fails, but I believe there is no problem. Invalid instruction: gcc-torture-execute-20090113-1.c tst_gcc-torture-execute-20090113-1 1 invalid instructions, (f: 1, t: 0, c: 0, b: 1526, T: 12574) From tst_gcc-torture-execute-20090113-1.out: Simulation started, PC=0x000000 Loading from gen/ucz80-undoc/tst_gcc-torture-execute-20090113-1.ihx...
-
Thank you Felix. Log files are attached. I got a bit further: The difference between 13600 (working) and 13601 (not working) is this: 13600: ../../bin/sdcc -I../../../device/include -I../../../device/include/mcs51 -mds390 --nostdinc --std-c11 -c ../../../device/lib/_atof.c -o ds390/_atof.rel 13601: /Users/Shared/Devel/Other/Z80/tools/sdcc-13601/sdcc/felix/bin/sdcc -mds390 --nostdinc --std-c11 -c ../../../device/lib/ds390/../_atof.c 13600 uses a relative path to sdcc, 13601 uses an absolute path....
-
Hi Felix, Yes, I did make clean distclean. I always do this before checking out another revision. I tried what you suggested, configure and make from a different directory, but I still get the same errors. When I tried building before, I had already made sure that SVN reported nothing as missing or unversioned or local-modified, ad reverted / deleted if it did. Another thing that strikes me as odd (but maybe it is normal): I use configure with a --prefix. configure gives me this error: configure:...
-
I can build trunk revision 13597 but not 13601 or later. (The 3 commits in between are not on trunk.) At time of writing this, HEAD is 13688. 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.3 #13590 (Mac OS X x86_64) Revision 13601 and up gives me: /Users/Shared/Devel/Other/Z80/tools/sdcc/sdcc/bin/sdcc -mds390 --nostdinc --std-c11 -c ds390/../_atof.c ds390/../_atof.c:29:19: error: no include path in which...
-
maybe you can derive a header file from a sym file in an automated manner I have solved a technically similar situation, albeit for a different use case: In ROM I have code that lets me load apps from SD card or UART into RAM and run from there. The ROM contains a bunch of modules for LCD screen, serial port, SPI, SD card, ... I wanted my apps, which run from RAM, to make use of the global functions in the ROM and the non-static variables defined by the ROM. Compiling and linking the ROM produces...
-
(Please someone correct me if this is totally wrong...) The variables in that .s file are different than the variables in your .c file. They are initialised, but only once. They are initialised to zero using .dw #0x0000 and .db #0x00 but if they get written, they do not get re-initialised when you run the program for the 2nd time. The variables in your .c file are either .. 1) not initialised - no need to take up space in the binary. Their address will be outside the binary. 2) initialised and const...
-
I am by no means an expert on SDCC, Z80, or MSX, but this does not seem wrong or strange to me. The .ihx file contains only everything that needs to be in memory before you can execute your program. But then, the program can access other memory. This is especially easy to imagine when your program runs in ROM. Any variables it uses must live in RAM. The variables in your screenshot are in the _INITIALIZED area. If these are things you never change, you can make them const.
-
In genXor(), changing cheapMove() to genMove_o() seems to do the trick, but I don't really understand why. @@ -9400,7 +9400,7 @@ genXor (const iCode *ic, iCode *ifx) { if (((lit >> (offset * 8)) & 0x0FFL) == 0x00L) { - cheapMove (result->aop, offset, left->aop, offset, a_free); + genMove_o (result->aop, offset, left->aop, offset, 1, a_free, isPairDead (PAIR_HL, ic), !isPairInUse (PAIR_DE, ic)); if (aopInReg (result->aop, offset, A_IDX)) a_free = false; continue; In shiftR2Left2Result(), this can...
-
In genXor(), changing cheapMove() to genMove_o() seems to do the trick, but I don't really understand why. @@ -9400,7 +9400,7 @@ genXor (const iCode *ic, iCode *ifx) { if (((lit >> (offset * 8)) & 0x0FFL) == 0x00L) { - cheapMove (result->aop, offset, left->aop, offset, a_free); + genMove_o (result->aop, offset, left->aop, offset, 1, a_free, isPairDead (PAIR_HL, ic), !isPairInUse (PAIR_DE, ic)); if (aopInReg (result->aop, offset, A_IDX)) a_free = false; continue; In shiftR2Left2Result(), this can...
-
Thank you Philipp. I looked it up and 98a is the same except it is specifically for ix, as you said. I guess the peephole only sees the assembly and can not tell what the original C was. But in the case where these repeated load/stores are generated from foo |= 1 where foo is long or long long, I'd think they do nothing useful even if foo is volatile. Do you have any recommended resources I can read and get better insight into these things? This is not something I have a problem with. Just something...
-
I decided to try and find out where and why and how these operations get generated in the first place, and see if they can be avoided rather than removing them after the fact. Thanks to --fverbose-asm is was not hard to find. When ANDing, ORing, or XORing something with a literal, there are already special cases when ORing or XORing with 0x00, or when ANDing with 0xFF. genAnd: else if (bytelit == 0xff) genOr: else if (bytelit == 0x00) genXor: if (((lit >> (offset * 8)) & 0x0FFL) == 0x00L) These all...
-
Thank you Phillip. I looked it up and 98a is the same except it is specifically for ix, as you said. I guess the peephole only sees the assembly and can not tell what the original C was. But in the case where these repeated load/stores are generated from foo |= 1 where foo is long or long long, I'd think they do nothing useful even if foo is volatile. Do you have any recommended resources I can read and get better insight into these things? This is not something I have a problem with. Just something...
-
Hello I am new to SDCC and to the Z80. (In the 1980s I had a 6502 machine.) Earlier this year I got 2 Z80 CPUs (but none of the support chips), so I built a simple computer on strip board. I ended up using SDCC to build some firmware and test apps for it. It works great. Thank you all for this nice tool. I noticed that sometimes the compiler generates two successive loads that are each others opposite, like lines 820 and 823 in the following snippet: 0166 39 [11] 816 add hl, sp 0167 7E [ 7] 817 ld...
1