This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New back end ia16: 16-bit Intel x86
- From: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 19 Aug 2007 18:35:31 +0200
- Subject: Re: New back end ia16: 16-bit Intel x86
- References: <20070819151306.6C61E749C2@caffeine.csclub.uwaterloo.ca>
On Sun, Aug 19, 2007 at 11:13:06AM -0400, Ross Ridge wrote:
> Rask Ingemann Lambertsen writes:
> >It doesn't seem to be a likely problem to me. Code operating on %sp
> >can't clobber the top half[1]. Code operating on %esp will need to
> >restore it or run into trouble. It would be very unusual to not restore
> >the stack pointer.
>
> Code that operates on SP only needs to set or restore SP to work
> correctly.
It also doesn't clobber the upper half of %esp, obviously it doesn't need
to restore it.
> >If this was to be a problem, you wouldn't be able to just use
> >".code16gcc".
>
> Yes.
>
> >[1] Strictly speaking, only bits 16-19 are of any concern.
>
> No. The full 32-bit segment offset is checked against the segment limit
> in both real mode and 16-bit protected mode. Even if that weren't the
> case, and it's possible to trick the CPU to use a segment limit other
> than 0xFFFF in real mode, all 32-bits of ESP would be used to calculate
> the 32-bit linear address.
I'm just going by the documented maximum real address mode address of
0xfffff. It's OK if the CPU raises an exception; my worry would have been
silent stack corruption.
--
Rask Ingemann Lambertsen