Or, at least, doesn't work as it should.
Most 51's (that have 256 bytes of memory) can have
stack in idata area (eg. stack beginning from 0xB0).
However, SDCC doesn't allow many of these, valid stack
beginning positions (eg. 0x76, which is default by
--stack-after-data in my prog, or 0xb0, way after last
idata variable, or ... well, you got the idea).
--stack-loc should accept any value between 0 and 255
(dec) user enters, whether it is valid or not.
Worse, "invalid" --stack-loc seems to result compiler
failing (terminating compilation) without even printing
out any error messages OR returning nonzero result.
Dunno whether this happens with other args or somewhere
else in compiler, but this (failing somehow without
telling user of it) definitely is a pretty serious flaw
(version 2.3.0, windows build)
(it took me three months without ICE and two hours with
one to figure out this problem (stack overflowing to
idata because of interrupts)... You can guess I wasn't
very thrilled when I found out what went wrong and that
I couldn't fix the problem...)
Log in to post a comment.