#261 failutre with --stack-loc


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
in compiler.

(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...)


  • Karl Bongers

    Karl Bongers - 2001-12-30

    Logged In: YES

    --stack-loc option is working fine from what I can tell.
    I tested recent code from CVS as well as the V2.3.0 winbin
    listed in the bug report. Using --stack-loc 180 I get
    mov sp, #180
    generated in the code.

    Toni, can you please give some more specifics about
    the problem you are seeing. Have you looked at the .asm
    file? You should find one
    line with the
    mov sp, #num
    in the startup.


  • Toni Räsänen

    Toni Räsänen - 2002-01-03

    Logged In: YES

    I used 2.3.0 msvc binaries from download page. Also, I
    verified the results with an ICE I had access to (easy,
    because mov sp, #xxx is, after all, second instruction
    program executes after reset). I tried --stack-loc in
    cflags, ldflags and in both. Most of the time compiler
    quitely quit execution, as I said, without printing any
    error messages and returning zero (so even make couldn't say
    something went wrong). I tried to use values 16 (default, as
    only two reg banks (0 & 1) are in use, 0x70, 0xa0, 0xb0 and
    190, and possibly some others, with this same result. (or
    it's possibly that compiler simply ignored it, too, can't be
    that sure about it).

    Program used is (if I remember correctly) currently about 3
    kbytes, having two modules, data area being at 0x20-0x74
    (end addres approximate, can't remember it), idata being at
    0x80-0x90 (also approximatly).

    (why I always, with every program I use, seem to find
    unreproducible errors is beyond me...)

    (interrupts use 5 bytes of stack, even if, say, dptr isn't
    used (it's still stored in stack)... someone might want to
    look into this, what a waste of memory, and source of very
    obscure errors, I found this with the aid of ICE and
    traceback command...)

    (also, it seems that linker happily lets data and idata
    overlap (as in data ending at 0x82, idata beginning in
    0x80). even more problems, if one doesn't check the .map

  • Johan Knol

    Johan Knol - 2002-01-07

    Logged In: YES

    --stack-after-data and --stack-loc are mutually exclusive
    but --stack-loc prevails

    Please supply an example where --stack-loc fails.

  • Johan Knol

    Johan Knol - 2002-01-07
    • milestone: 100454 --> unreproducable
    • priority: 5 --> 2
    • status: open --> open-works-for-me
  • Johan Knol

    Johan Knol - 2002-01-15
    • status: open-works-for-me --> closed-works-for-me

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks