On Tue, 20 Jan 2009 08:49:12 -0500, Rich Webb wrote:

> On Tue, 20 Jan 2009 06:09:55 -0600, "runin225" <runin225@gmail.com>
> wrote:
> 
>>Hi Friends,
>>
>>I'm using sdcc 2.8.0 #5117 to build code for a 8051 derivative that has
>>256 byte internal RAM.
>>I'm using a small model and for some reason I'm unable to use the entire
>>memory.
>>When I look at the memory map I see that the sdcc uses the upper 128B

 -- snip --
> 
> On the other hand, while the MCS51-family can handle external memory
> pretty well, if you're limited to just the internal memory area then you
> might be better off staying with assembly.

I've programmed for itty bitty chips in this circumstance, with C, and it 
works just fine.  You have to pay attention to the restricted memory with 
every line of code you write, but it can be done, and IMHO it's a 
significant time-saver for all but the most accomplished of assembler 
coders (particularly when said assemble coder wants to retire, or go on 
vacation).

-- 
http://www.wescottdesign.com

On Tue, 20 Jan 2009 16:13:19 +0200, Mika Iisakkila
<mika+nyys@pingrid.fi.invalid> wrote:

>Rich Webb <bbew.ar@mapson.nozirev.ten> writes:
>> 1.2.2 Indirect Addressing
>> In indirect addressing the instruction specifies a register which
>> contains the address of the operand. Both internal and external RAM can
>> be indirectly addressed. The address register for 8-bit addresses can be
>> R0 or R1 of the selected register bank, or the Stack Pointer. The
>> address register for 16-bit addresses can only be the 16-bit
>> &#4294967295;data pointer&#4294967295; register, DPTR."
>>
>> IIRC, there is a way to tell sdcc to use that upper 128 byte region. Is
>> the _xdata tag only for "real" external memory?
>
>I suppose so, since while internal and external RAM are bundled
>in 1.2.2 above, they need separate machine instructions (and there is
>even one more addressing mode, indirect addressing of program memory).
>
>I know diddly squat about sdcc, but the upper half of the internal
>memory probably requires another classifier (idata or something), and

__idata it is indeed (and external is __xdata, vice _xdata, my bad).

>the linker may also need to be instructed on how to split that area
>between stack and variables. There might also be different memory
>models for the compiler which will do this more or less transparently.

It looks like the linker defaults to placing __idata variables at the
bottom of the indirect memory area and the stack grows down from the top
thereof. The other MCS51 memory models (medium and large) need external
RAM so small looks like the way to go, with due care, as you note, to
the stack.

>> On the other hand, while the MCS51-family can handle external memory
>> pretty well, if you're limited to just the internal memory area then you
>> might be better off staying with assembly.
>
>C is just fine if you don't overdo automatic variables and nested
>function calls, in which case you will quickly find yourself with a
>stack overflow. Of course it will be closer and closer to using a
>glorified macro assembler...

True that.

-- 
Rich Webb     Norfolk, VA

Rich Webb <bbew.ar@mapson.nozirev.ten> writes:
> 1.2.2 Indirect Addressing
> In indirect addressing the instruction specifies a register which
> contains the address of the operand. Both internal and external RAM can
> be indirectly addressed. The address register for 8-bit addresses can be
> R0 or R1 of the selected register bank, or the Stack Pointer. The
> address register for 16-bit addresses can only be the 16-bit
> &#4294967295;data pointer&#4294967295; register, DPTR."
>
> IIRC, there is a way to tell sdcc to use that upper 128 byte region. Is
> the _xdata tag only for "real" external memory?

I suppose so, since while internal and external RAM are bundled
in 1.2.2 above, they need separate machine instructions (and there is
even one more addressing mode, indirect addressing of program memory).

I know diddly squat about sdcc, but the upper half of the internal
memory probably requires another classifier (idata or something), and
the linker may also need to be instructed on how to split that area
between stack and variables. There might also be different memory
models for the compiler which will do this more or less transparently.

> On the other hand, while the MCS51-family can handle external memory
> pretty well, if you're limited to just the internal memory area then you
> might be better off staying with assembly.

C is just fine if you don't overdo automatic variables and nested
function calls, in which case you will quickly find yourself with a
stack overflow. Of course it will be closer and closer to using a
glorified macro assembler...
-- 
http://www.hut.fi/u/iisakkil/		--Foo.

On Tue, 20 Jan 2009 06:09:55 -0600, "runin225" <runin225@gmail.com>
wrote:

>Hi Friends,
>
>I'm using sdcc 2.8.0 #5117 to build code for a 8051 derivative that has
>256 byte internal RAM.
>I'm using a small model and for some reason I'm unable to use the entire
>memory.
>When I look at the memory map I see that the sdcc uses the upper 128B for
>stack, and does not permit data to reside there. I've tried reducing the
>stack size and change the location of different memory components; I've
>also used the pack/nopack options, but I wasn't able to use more than 128B
>for data.
>
>Does anyone know if that's doable and how?

Haven't danced with an 805x for a while but this may be relevant:

"1.2  Addressing Modes
The addressing modes in the 8051 instruction set are as follows:

1.2.1 Direct Addressing
In direct addressing the operand is specified by an 8-bit address field
in the instruction. Only 128 Lowest bytes of internal Data RAM and SFRs
can be directly addressed.

1.2.2 Indirect Addressing
In indirect addressing the instruction specifies a register which
contains the address of the operand. Both internal and external RAM can
be indirectly addressed. The address register for 8-bit addresses can be
R0 or R1 of the selected register bank, or the Stack Pointer. The
address register for 16-bit addresses can only be the 16-bit
&#4294967295;data pointer&#4294967295; register, DPTR."

IIRC, there is a way to tell sdcc to use that upper 128 byte region. Is
the _xdata tag only for "real" external memory?

On the other hand, while the MCS51-family can handle external memory
pretty well, if you're limited to just the internal memory area then you
might be better off staying with assembly.

-- 
Rich Webb     Norfolk, VA

Hi Friends,

I'm using sdcc 2.8.0 #5117 to build code for a 8051 derivative that has
256 byte internal RAM.
I'm using a small model and for some reason I'm unable to use the entire
memory.
When I look at the memory map I see that the sdcc uses the upper 128B for
stack, and does not permit data to reside there. I've tried reducing the
stack size and change the location of different memory components; I've
also used the pack/nopack options, but I wasn't able to use more than 128B
for data.

Does anyone know if that's doable and how?

Thanks,
Runin