Activity for Visenri
-
Visenri committed [df1967] on Experimental Mirror (Git)
Fix bug in pdk15 simulation (introduced in [r12557]).
-
Fix parsing of test name.
-
Fix bug #3269.
-
Added infrastructure to test pdk13.
-
Lightweight version of test framework (testfwk) [#393].
-
Added processing for the stack overflow message from simulator.
-
Added assembler support for new pdk .io mnemonics (bug #3259).
-
Added support for stack overflow detection.
-
Added builtins: "__builtin_rlc", "__builtin_rrc" & "__builtin_swap".
-
Fixed Changelog
-
Implemented partial support for conditional type reduction (patch #392), for now only used by SIZEOF.
-
Added support for pdk in test bug2686159.
-
STM8 - Multiple improvements regarding peephole rules & argCont function.
-
STM8 - Added missing rule 625a from my pack #6 from patch #362, fixed tabs/spaces.
-
Fixed buffer overflow in operand string in "immdInRange" function
-
STM8 - Removed unneeded optimizations for SWAP after r12420 / Fixed changelog date.
-
STM8 - Fixed Typo regarding 'jrsgt' instruction - Rules 600a & 600b from patch #362
-
Peephole rules pack - savings for bitfields operations
-
Ok, I'm closing it.
-
I have been busy with other projects and this ticket has been open for too long. I really would like to fix the problems described in this topic. But maybe we have to rethink how to fix them, because other backends also suffer from similar problems: See [#3291] I see multiple issues: Defects in asm parsing, some times flagging 'x' or 'y' as used when they are not, both in generated asm from compiler or inline asm. Defects in asm parsing when some extra space or tab is present: my set of extra functions...
-
As I said some months ago, after [r12449]: ...the state of this patch is: Done, pure reordering rules not applied and no longer needed (120 & 121): Done. Done Not applied because it is pure reordering. Done Done As I said, there is margin for improvement, but I think all that could be applied safely has been applied. Even thought there are potential problems (endless loops)) with with pure reordering rules (pack 4). I've never seen them in all my testing, because no other rule seems to undo the changes...
-
Maybe we can make this the default version to save memory for all devices. For now I would keep it only for pdk13 and pdk14 because it will affect all regression tests outputs (All will show less bytes and less cycles). Once all the test results are generated with the automated tests and we check there are no differences, we can enable it for other backends (I've checked it locally, but as seen in [feature-requests:#144], what we get with the test farm is not exactly the same).
-
Thanks. In [r12609], the issue is fixed, though I went a bit further than the patch.
-
I was not able to reproduce it in my test machine, but I found a problem in the code that could make pdk15 simulation fail randomly. It was just a missing initialization. Should be fixed in [r12575].
-
Fix bug in pdk15 simulation (introduced in [r12557]).
-
Python script fixed (or I hope so) in [r12574]. But the issue with pdk tests remains unanswered.
-
Fix parsing of test name.
-
I can reproduce the issue regarding the python script, but not the pdk test failure. I was not aware of the valdiag tests!. I will fix the python script ASAP.
-
After all the patches commited [r12557], [r12558],[r12559], [r12560], [r12561] & [r12566], it seems that pdk is failing: http://sdcc.sourceforge.net/regression_test_results/aarch64-unknown-freebsd13.0/regression-test-aarch64-unknown-freebsd13.0-20210727-12566.log http://sdcc.sourceforge.net/regression_test_results/x86_64-apple-macosx/regression-test-x86_64-apple-macosx-20210727-12566.log But in my machine, all pdk tests finish successfully. May I see the output of the simulator of those tests? Can...
-
After all the patches commited [r12557], [r12558],[r12559], [r12560], [r12561] & [r12566], it seems that pdk is failing: http://sdcc.sourceforge.net/regression_test_results/aarch64-unknown-freebsd13.0/regression-test-aarch64-unknown-freebsd13.0-20210727-12566.log http://sdcc.sourceforge.net/regression_test_results/x86_64-apple-macosx/regression-test-x86_64-apple-macosx-20210727-12566.log But in my machine, all pdk tests finish successfully. May I see the output of the simulator of those tests? Can...
-
pdk code generation - copy from not initialized temporary variable
-
Fixed in [r12566]
-
Fix bug #3269.
-
Found and fixed wrong code in src/pdk/gen.c genGetByte: - cheapMove (ASMOP_A, 0, left->aop, offset, regDead (A_IDX, ic), regDead (P_IDX, ic), true); + genMove_o (result->aop, 0, left->aop, offset, 1, regDead (A_IDX, ic), regDead (P_IDX, ic)); I will commit after checking the tests.
-
pdk code generation - copy from not initialized temporary variable
-
pdk code generation - copy from not initialized temporary variable
-
pdk code generation - copy from not initialized temporary variable
-
Of course, I completely agree. It was just not necessary right now. I will implement the remaining mnemonics ASAP.
-
You can see some examples of the new macros in use in the patch I plan to commit in the next days:
-
Implemented in [r12558]. For the case discussed, "sp" and "f" used without .io instruction, I've implemented a warning for now. I have not implemented these mnemonics for pdk16 because they were not present originally, and pdk16 is not testable right now: SWAPC.IO TOG.IO WAIT0.IO WAIT1.IO I have modified/implemented this mnemonic (valid for pdk14-16) because it was present originally. SWAPC.IO pdk14-16 But it is not used by the code generator, so untested (as it was).
-
The infrastructure is ready in [r12561]. We can start reviewing/patching the required tests. I hope someone will join me, because the number of tests is very big for one person. As I said, the pdk13 is excluded from the automatic list, you will have to test it manually: make test-pdk13 Remember: do not work on the ones I have already posted above.
-
Commited in [r12560]
-
Added infrastructure to test pdk13.
-
Lightweight version of test framework (testfwk) [#393].
-
Added processing for the stack overflow message from simulator.
-
Added assembler support for new pdk .io mnemonics (bug #3259).
-
Added support for stack overflow detection.
-
I will publish here the list I am working on. I suggest to work in batches and post here the list you are working on as soon as you start. I attach here the list of the test I've already done (I will commit ASAP).
-
Test review for pdk13 & pdk14 - Volunteers needed
-
Test review for pdk13 & pdk14 - Volunteers needed
-
Maybe we can make this the default version to save memory for all devices. For now I would keep it only for pdk13 and pdk14 because it will affect all regression tests outputs (All will show less bytes and less cycles). Once all the test results are generated with the automated tests and we check there are no differences, we can enable it for other backends (I've checked it locally, but as seen in [#144], what we get with the test farm is not exactly the same).
-
Lightweight version of test framework (testfwk)
-
I have a working version (passes all tests) with the required changes for the new mnemonics, but several questions have arisen: I have changed all places using io address space in gen.c to use the new ".io" mnemonic, but as I was doing the changes I thought: Should the assembler show an error in these contradictory cases?: mnemonic without ".io" used with "sp" or "f" (both in "io" space). mnemonic with ".io" used with "p" (in memory space). The alternative would be to tolerate both mnemonics only...
-
I have a working version (passes all tests) with the required changes for the new mnemonics, but several questions have arisen: I have changed all places using io address spaces in gen.c to use the new ".io" mnemonic, but as I was doing the changes I thought: Should the assembler show an error in these contradictory cases?: mnemonic without ".io" used with "sp" or "f" (both in "io" space). mnemonic with ".io" used with "p" (in memory space). The alternative would be to tolerate both mnemonics only...
-
Fixed rest of cases in [r12547]. ConstVal, shifts & ptrdiff. All cases tested with new "sizeof.c" test.
-
Added builtins: "__builtin_rlc", "__builtin_rrc" & "__builtin_swap".
-
Progress done up to now, commited in [r12528]. There is still some some work to do to check all cases (constVal calls, some shift cases and maybe others).
-
Fixed Changelog
-
Implemented partial support for conditional type reduction (patch #392), for now only used by SIZEOF.
-
Another subtle difference is in /regression/gen/mcs51-medium/fkw.lib: Old MSYS2 statics.rel extern1.rel extern2.rel T2_isr.rel New MSYS2: statics.rel extern1.rel extern2.rel T2_isr.rel T2_isr.rel T2_isr.rel But this should not affect the simulator.
-
Thanks for the information, but I was looking for more details. The configure log would be useful, to compare any other details.
-
I've compared the .map and .ihx of: "implict_int" and "driverstruct" and they are exactly the same. So, to me, the problem must be in the simulator. The comparison has been done using my two build system, old with gcc 7.3.0 and new with 10.3.0. I've disables support for treedec in both tests. Any ideas about what could cause this behavior? Attached: files for "implicit_int" output.
-
I've re-run the same tests with the new updated system but without the tdlib. As expected per your description there is no difference between using it in this case or not for mcs51-medium. With pdk15-stack-auto the difference is very minimal: 4619082 bytes, 89230255 ticks (SDCCtree_dec) 4619238 bytes, 89230272 ticks (tdlib) With stm8-large it is bigger: 3753619 bytes, 86713751 ticks (SDCCtree_dec) 3749694 bytes, 86866482 ticks(tdlib) But no test matches the snapshot page results. The best matches...
-
I tried the newest MSYS2 (Mingw) packages and tried to use the library you said. I assume this is the newest version: https://github.com/freetdi/tdlib After some trouble( * see bellow) getting it to compile, I finally compiled and installed it successfully. Results are a mixed bag: stm8-large:It still does not match the snapshots logs, I have even more differences than before. I get better code size, but worse cycles: Case Results Differences with snapshot SDCCtree_dec 3753619 bytes, 86713751 ticks...
-
Updated my whole dev enviroment tools, using gcc 10.3.0 and still the same result. And now I get extra lines in each test (no problem for my python script, but were not generated previously): make[3]: Entering directory '/XXXX/sdcc_12510/support/regression' make[3]: Leaving directory '/XXXX/sdcc_12510/support/regression' swap (f: 0, t: 6, c: 1, b: 1324, T: 4631)
-
Regression tests results do not match local copy
-
Regression tests results do not match local copy
-
By the way - Comparison note. Other compilers have exactly the same "issue" with pointer sizes not being consistent with the standard, for example microchip XC8 for 8 bit pics, they just state this in the manual: Divergence from the C90 Standard: The C sizeof operator when acting on pointer types or on structure or array types that contain a pointer may not work reliably. This operator, however, may be used with pointer, structure, or array identifiers. This is due to the dynamic nature of pointer...
-
My testing with the current patch state has improved a lot the situation for a lot of ports: 220 failures of 576 tests vs 0 failures of 576 tests. So it is an improvement with no loss, even if it does not fix all problems mentioned. Tests of SIZEOF for ports that don't have intrinsic name spaces with different pointer sizes don't need any special test. To make the tests involving intrinsic named spaces pass, I adapted the tests to check for it, and give 0 failures with current behavior, the other...
-
PDK: Wrong opcodes for absolute memory and IO (SFR) spaces (MOV, XOR...)
-
PDK: Wrong opcodes for absolute memory and io (SFR) spaces (MOV, XOR...)
-
I was looking right now at those instructions too, there is another one, TOG, for pdk16. No big deal, just follow the same pattern. This would be the complete list. MOV.IO XOR.IO T0SN.IO T1SN.IO SET0.IO SET1.IO TOG.IO WAIT0.IO WAIT1.IO SWAPC.IO T2SN does not exist, a typo, I suppose :D.
-
I was also able to fix the problem for the SFR with initialization, using the data from the section and checking if it is in a "RSEGx" section, the generation of RAM addressing can be avoided. But the case with absolute RAM and no initialization is not easily fixable without adding new features to the assembler, that is one of the reasons why I think the best option is new mnemonics. The other reason as already said is that other backends already do it that way. Changes in pdkadr.c (would not be...
-
I was also able to fix the problem for the SFR with initialization, using the data from the section and checking if it is in a "RSEGx" section, the generation of RAM addressing can be avoided. But the case with absolute RAM and no initialization is not easily fixable without adding new features to the assembler, that is one of the reasons why I think the best option is new mnemonics. The other reason as already said is that other backends already do it that way. Changes in pdkadr.c (would not be...
-
Yesterday I also found more problems, other backends also have problems with initialization in variables using the __sfr qualifier. But at least, they directly stop with an error. Z80 for example fails with this error: Error: <o> .org in REL area or directive / mnemonic error Error: <q> missing or improper operators, terminators, or delimiters Regarding these lines, there is an org with a missing section: .org 0x0078 _REG_SFR:: .ds 1 Initializers for absolute addresses seem to work fine. But that...
-
I am also no expert in pdk assembler, but I did a self-taught accelerated course yesterday I also arrived to that same conclusion about the new mnemonic yesterday. This is the way it is handled for other backends, different instructions for different opcodes (for example: "in" and "out" for sfr). The assembler has no easy way of knowing, because the assembler does not store (in some cases) the needed information to use the right opcode. It should be easy to fix it in gen.c, and check if any rules...
-
Side note: the tests pass, because they don't test whether the memory space is the correct one or not, only if the write / read was successful. Once someone else confirms that this behavior is not the expected one, I will write tests to check that the memory space is the same using the different cases and also that writing one does not affect the others. I am 90% sure it is not OK, but I am not familiar with this kind of subtle details in SDAS directives, and documentation is not very good / not...
-
It looks like that the .area where the symbol is defined or space is reserved is not taken into account. It only seems to care about space storage, if the symbol is from a .ds it handles it as RAM, otherwise it is IO. I think this is incorrect and related to this code in pdkadr.c, look at the default case, constants with no area information?: addr(struct expr *esp) { int c = getnb(), c1; switch (c) { case '#': /* Immediate mode */ .............. case 'a': /* Accumulator */ .............. case 's':...
-
After some more tests and learning of pdk asm I have new findings. It seems that addressing is not done correctly by assembler: Absolute variables with no initializer are handled as IO space, generating wrong opcodes. On the other side, using initializers with SFR you get RAM addressing!. What we get: _ SFR ABS VAR REL VAR NO INIT IO IO(1) RAM INIT RAM (2) RAM RAM What is should be: _ SFR ABS VAR REL VAR NO INIT IO RAM RAM INIT IO RAM RAM For reference (pdk15): Ram opcode: _: ; PC ADDRESS address(8...
-
Added support for pdk in test bug2686159 : [r12498].
-
Added support for pdk in test bug2686159.
-
PDK problem with absolute addressing in OR (maybe also others)
-
I've corrected my words of the last paragraph, I wrote that "pcd" is a generic pointer when it's clearly not.
-
After some more testing and reading C standards: These are the test that keep failing: FAIL: "Assertion failed" on (i = sizeof (&i), sizeof (int *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:92 FAIL: "Assertion failed" on (c = sizeof (&i), sizeof (int *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:93 FAIL: "Assertion failed" on (i = sizeof (&c), sizeof (char *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:94 FAIL: "Assertion failed" on (c = sizeof (&c), sizeof (char *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:95...
-
After some more testing and reading C standards: These are the test that keep failing: FAIL: "Assertion failed" on (i = sizeof (&i), sizeof (int *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:92 FAIL: "Assertion failed" on (c = sizeof (&i), sizeof (int *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:93 FAIL: "Assertion failed" on (i = sizeof (&c), sizeof (char *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:94 FAIL: "Assertion failed" on (c = sizeof (&c), sizeof (char *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:95...
-
Side note: It took me a while to figure this out, but to do this test properly, I had to comment this line from testfwk.h: #if defined(__SDCC_pdk13) || defined(__SDCC_pdk14) || defined(__SDCC_pdk15) //# define __data Otherwise each time I want to use the "__data" qualifier it was replaced by nothing by the preprocessor (but you don't realize that by looking at the asm files). I was looking at the asm files and was getting different results for the pointers for the same written code using it in this...
-
Side note: It took me a while to figure this out, but to do this test properly, I had to comment this line from testfwk.h: #if defined(__SDCC_pdk13) || defined(__SDCC_pdk14) || defined(__SDCC_pdk15) //# define __data Otherwise each time I want to use the "__data" qualifier it was replaced by nothing by the preprocessor (but you don't realize that by seein the asm files). I was looking at the asm files and was getting different results for the pointers for the same written code using it in this test...
-
After some more testing and reading C standards: These are the test that keep failing: FAIL: "Assertion failed" on (i = sizeof (&i), sizeof (int *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:92 FAIL: "Assertion failed" on (c = sizeof (&i), sizeof (int *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:93 FAIL: "Assertion failed" on (i = sizeof (&c), sizeof (char *) == i) at gen/pdk15/test_sizeof/test_sizeof.c:94 FAIL: "Assertion failed" on (c = sizeof (&c), sizeof (char *) == c) at gen/pdk15/test_sizeof/test_sizeof.c:95...
-
Results after testing other backends: Regarding xor optimization: Most (if not all) seem to benefit (size and cycles) from the OR-XOR optimization (similar to STM8). pdk fails because it generates invalid code: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genOr mov a, #0x01 or _REG_2+0, a ; gen/pdk14/bug2686159/bug2686159.c: 32: REG_2 |= 2; ; genOr mov a, #0x02 or _REG_2+0, a It was like this before the patch: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genAssign mov a, _REG_2+0...
-
Regarding conditional type reduction and results of "sizeof" tests: All backends have an improvement (less tests fail). Failures with trunk version: mcs51 117/244 others (not including pdk): 108/244. Failures after patch: ds390/mcs51 8/244 others (not including pdk): 0/244. Pdk seems to fail because of lack of memory and also timeout, even when testing only for size variables (define only TEST_VARIABLE or TEST_LITERAL, others undefined). Will do more testing with simpler test files. Some ports backends...
-
The tests that keep failing after the patch are the test of pointer size.
-
Results after testing other backends: Regarding xor optimization: Most (if not all) seem to benefit (size and cycles) from the OR-XOR optimization (similar to STM8). pdk fail because it generates invalid code: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genOr mov a, #0x01 or _REG_2+0, a ; gen/pdk14/bug2686159/bug2686159.c: 32: REG_2 |= 2; ; genOr mov a, #0x02 or _REG_2+0, a It was like this before the patch: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genAssign mov a, _REG_2+0...
-
Regarding conditional type reduction and results of "sizeof" tests: All backends have an improvement (less tests fail). Failures with trunk version: mcs51 117/244 others (not including pdk): 108/244. Failures after patch: ds390/mcs51 8/244 others (not including pdk): 0/244. Pdk seems to fail because of lack of memory and also timeout, even when testing only for size variables (define only TEST_VARIABLE or TEST_LITERAL, others undefined). Will do more testing with simpler test files. Some ports backends...
-
Results after testing other backends: Regarding xor optimization: Most (if not all) seem to benefit (size and cycles) from the OR-XOR optimization (similar to STM8). pdk fail because it generates invalid code: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genOr mov a, #0x01 or _REG_2+0, a ; gen/pdk14/bug2686159/bug2686159.c: 32: REG_2 |= 2; ; genOr mov a, #0x02 or _REG_2+0, a It was like this before the patch: ; gen/pdk14/bug2686159/bug2686159.c: 31: REG_2 |= 1; ; genAssign mov a, _REG_2+0...
-
OR - XOR cast optimization - CONDITIONAL type reduction in AST
-
After adding extra tests, only minor changes were needed to allow almost all operators to be OK. Aside from adding the extra parameter to decorateType (and passing it to valXX functions) only minimal changes were needed in these operators: & | ^ unary+ LEFT_OP RIGHT_OP So far, it passes all tests (160) involving many (almost all) operators combined with pure literals and literals with values. The only tests that fail are boolean operators, I have to check them, just handle them as integers: ! all...
-
Does SDCC support auto variables (introduced in C++11)? You meant something like this: auto autoVar = 1; auto autoVarWithOp = 1 + 1; ASSERT(sizeof (autoVar) == sizeof (int)); ASSERT(sizeof (autoVarWithOp) == sizeof (int)); The SDCC documentation says nothing about this feature, and it gives me an error (as expected): error 226: no type specifier for 'autoVar' Compiles fine in gcc and executes tests correctly in host. So, if this is what you meant, it's not applicable right now to SDCC. Not a concern...
-
After confirming that the problem with those 4 cases was the use of RESULT_TYPE_OTHER (as expected), I added a boolean parameter to specifically disable size reduction for SIZEOF trees. Now 11 tests get better size and cycles with a total reduction of 1398 bytes (1200 from rotate2 tests as before). No tests with increased code size or cycles. As soon as I test all the operators and backends I'll upload the patch here so other developers can have a look at it, if no one has objections I'll apply the...
1 >