[Larceny-users] SCE_BUFFER?

[Lars T Hansen]

Can somebody tell me why SCE_BUFFER (aka $sce.buffer), which appears
to be some kind of red zone for the stack, was introduced into the
runtime and why it was only done in some realizations? Neither Sparc
nor Standard-C make use of it. I'm looking at code in a recent SVN
checkout but I've not attempted to find out when it was introduced.

--lars

[Felix S Klock II (Larceny-users list proxy)]

Lars (cc'ing larceny-users)-

If I recall correctly, Jesse Tov and I introduced the SCE_BUFFER to
support using the $esp register on Intel as the stack-cache pointer
(rather than the globals pointer, which I think was its role back when
you first developed the Petit/Nasm backend).

The reason to use $esp as the stack-cache pointer is that it enables a
significantly faster call/return instruction sequence on Intel; see:

https://trac.ccs.neu.edu/trac/larceny/changeset/4000

The reason we need a red-zone between the stack-cache and the nursery
is that you need some space above $esp in order to properly handle
interrupts or asynchronous signals or something along those lines.
(The notes on changeset:4000 don't actually 100% coincide with this
assertion, so I'm sure I'm getting the details wrong in this email.)

The reason its only present on some realizations is that you only need
this red zone on Native Intel backends (Petit/Nasm and Sassy/IA32 aka
IAssassin), because that's the only place where $esp is being used in
this way.

Cheers,
-Felix

Post by Lars T Hansen
Can somebody tell me why SCE_BUFFER (aka $sce.buffer), which appears
to be some kind of red zone for the stack, was introduced into the
runtime and why it was only done in some realizations? Neither Sparc
nor Standard-C make use of it. I'm looking at code in a recent SVN
checkout but I've not attempted to find out when it was introduced.
--lars
_______________________________________________
Larceny-users mailing list
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Felix S Klock II (Larceny-users list proxy)]

Follow-up with relevant wiki links (roughly in order of supposed relevance):

https://trac.ccs.neu.edu/trac/larceny/wiki/ContIsEsp

https://trac.ccs.neu.edu/trac/larceny/wiki/SassyInvoke

https://trac.ccs.neu.edu/trac/larceny/wiki/IntelsOptimizationRules

https://trac.ccs.neu.edu/trac/larceny/wiki/IAssassinSetrtnInvoke

Cheers,
-Felix

On Wed, Jul 11, 2012 at 11:08 AM, Felix S Klock II (Larceny-users list

Post by Felix S Klock II (Larceny-users list proxy)
Lars (cc'ing larceny-users)-
If I recall correctly, Jesse Tov and I introduced the SCE_BUFFER to
support using the $esp register on Intel as the stack-cache pointer
(rather than the globals pointer, which I think was its role back when
you first developed the Petit/Nasm backend).
The reason to use $esp as the stack-cache pointer is that it enables a
https://trac.ccs.neu.edu/trac/larceny/changeset/4000
The reason we need a red-zone between the stack-cache and the nursery
is that you need some space above $esp in order to properly handle
interrupts or asynchronous signals or something along those lines.
(The notes on changeset:4000 don't actually 100% coincide with this
assertion, so I'm sure I'm getting the details wrong in this email.)
The reason its only present on some realizations is that you only need
this red zone on Native Intel backends (Petit/Nasm and Sassy/IA32 aka
IAssassin), because that's the only place where $esp is being used in
this way.
Cheers,
-Felix

Post by Lars T Hansen
Can somebody tell me why SCE_BUFFER (aka $sce.buffer), which appears
to be some kind of red zone for the stack, was introduced into the
runtime and why it was only done in some realizations? Neither Sparc
nor Standard-C make use of it. I'm looking at code in a recent SVN
checkout but I've not attempted to find out when it was introduced.
--lars
_______________________________________________
Larceny-users mailing list
https://lists.ccs.neu.edu/bin/listinfo/larceny-users

[Lars T Hansen]

Thanks. ISTR that the 80386 needed a red zone to handle interrupts
and that that was fixed later, but it makes sense that signal handling
would still be using the user stack. I don't know that I had ever
considered that. Unices have a method of diverting the signal handler
to a separate stack (sigstack / sigaltstack), don't know if it's
entirely reliable or more widely available (eg Windows).

--lars

On Wed, Jul 11, 2012 at 5:22 PM, Felix S Klock II (Larceny-users list

Post by Felix S Klock II (Larceny-users list proxy)
https://trac.ccs.neu.edu/trac/larceny/wiki/ContIsEsp
https://trac.ccs.neu.edu/trac/larceny/wiki/SassyInvoke
https://trac.ccs.neu.edu/trac/larceny/wiki/IntelsOptimizationRules
https://trac.ccs.neu.edu/trac/larceny/wiki/IAssassinSetrtnInvoke
Cheers,
-Felix
On Wed, Jul 11, 2012 at 11:08 AM, Felix S Klock II (Larceny-users list

Post by Felix S Klock II (Larceny-users list proxy)
Lars (cc'ing larceny-users)-
If I recall correctly, Jesse Tov and I introduced the SCE_BUFFER to
support using the $esp register on Intel as the stack-cache pointer
(rather than the globals pointer, which I think was its role back when
you first developed the Petit/Nasm backend).
The reason to use $esp as the stack-cache pointer is that it enables a
https://trac.ccs.neu.edu/trac/larceny/changeset/4000
The reason we need a red-zone between the stack-cache and the nursery
is that you need some space above $esp in order to properly handle
interrupts or asynchronous signals or something along those lines.
(The notes on changeset:4000 don't actually 100% coincide with this
assertion, so I'm sure I'm getting the details wrong in this email.)
The reason its only present on some realizations is that you only need
this red zone on Native Intel backends (Petit/Nasm and Sassy/IA32 aka
IAssassin), because that's the only place where $esp is being used in
this way.
Cheers,
-Felix

Post by Lars T Hansen
Can somebody tell me why SCE_BUFFER (aka $sce.buffer), which appears
to be some kind of red zone for the stack, was introduced into the
runtime and why it was only done in some realizations? Neither Sparc
nor Standard-C make use of it. I'm looking at code in a recent SVN
checkout but I've not attempted to find out when it was introduced.
--lars
_______________________________________________
Larceny-users mailing list
https://lists.ccs.neu.edu/bin/listinfo/larceny-users