sr (nobody.delete@this.nowhere.com) on October 1, 2021 1:04 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on September 25, 2021 3:44 pm wrote:
>
> > You can't really, without horrendous impact, divide stack
> > from data on x86. Pointers from both are constantly
> > intermixed. You could move some stack data (register save
> > areas, return addresses, etc.) to a separate parallel
> > stack (like IPF did, and to an extent SPARC), and that
> > could have significant benefits (if you can't overrun
> > an allocated item on the stack and hit a return address,
> > you can't modify return addresses that way), but that
> > requires substantial code overhead to implement (which isn't
> > helped by x86 segmentation), or substantial hardware
> > support (and the RSE on IPF had bugs for mostly the entire existence of the architecture).
> >
> > As for separating code from data - the NX and W bits in the page tables do that pretty simply.
>
>
> But did i386 designers get rid of that kind of problems? You could use 32 bit address pointers
> to stack and effective address is calculated from stack start address. So operation can be
> made totally transparent to code and maintain benefits of dividing stack from data?


Not really. Stack accesses continue to be relative to SS, (normal) data access to DS. But the problem is pointers to both get passed all over the place. Consider:

int global;
void f()
{
int local;
int *allocated = malloc(sizeof int);
g(&global, &local, allocated);
}

If you put the stack (assuming conventional stack allocation on x86) in a different segment (or not one aliased with DS), you now have to pass far pointers to g(). The performance overhead of that is why (general) large model programs were so disfavored in the 16-bit era. Many programs ended up mixed model so that they could use more memory, without that overhead.

It would have been possible to map the descriptors for DS and SS to different linear addresses, and then use page permissions to vary what's allowed to be accessed from that descriptor. But that doesn't really fix the above problem, since g() would be expecting a "general" address, so the differences in access allowed would only be applicable in the wrong direction). A down side of that would be a performance hit, at the very least due to increased TLB pressure, possibly some due to alias resolution issues.