My two cents worth(and questions):
This is a problem for --model-large, not just for 24-bit model, right?
Does your code fix the problem in large model as well?
Should it do pretty much the same code generation for small model?
I would like to see it in the main line code, unless the various
memory models are so disparate that it logically makes sense to break
up the code for the models.
Does it make sense to you to break up the memory models into separate
Is the code becoming to unweldy with all the memory models MCS51 tries to
If its really changed a lot, I think it would ultimately be up to
Sandeep on how/if/where to use it.
At 11:14 AM 3/30/00 -0700, you wrote:
>Sandeep et al,
> I have been merrily hacking away on getting sdcc to spill into the
>xdata segment in flat24 mode. I finally have this mostly working; at
>least well enough to start thinking about checking in my work.
> The problem is that this has required pretty extensive abuse of
>the code generator. It's gotten to the point that I am beginning to
>think that I should check this in as a seperate port (i.e. it really
>doesn't look all that much like the mcs51 code generator any more,
>though of course it's based on it).
> On the other hand, one think I've learned over the years is that
>copying the same code (like, say, ralloc.c, which is largely
>unchanged) into seperate projects is a recipe for later problems as
>the two versions get out of synch.
> So, does anybody have any preferences on this? I'm leaning towards
>checking this in as a new port, to avoid adding bloat and possible
>breakage of the mcs51 port, and dealing with the code duplication
>issues as they come up. But if you disagree, this is the time to