* Re: Why large stack frame for PAL call
2004-06-27 17:42 Why large stack frame for PAL call Chen, Kenneth W
@ 2004-06-29 5:50 ` David Mosberger
2004-06-29 14:11 ` n0ano
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: David Mosberger @ 2004-06-29 5:50 UTC (permalink / raw)
To: linux-ia64
>>>>> On Sun, 27 Jun 2004 10:42:14 -0700, "Chen, Kenneth W" <kenneth.w.chen@intel.com> said:
Ken> Does anyone know why we need such large stack frame for PAL
Ken> static call? PAL isn't even suppose to touch any stack
Ken> register for static calling convention. Is it for legacy
Ken> reason or something?
Good question. I was able to track the source down to a patch that
was sent to me by Walt Drummond on Aug 11, 1999. The authors listed
in the relevant file (it was called palcall.S back then) were Don
Dugger and Walt Drummond (in this order), so my guess is the code was
originally written by Don. At that time, the primary target for Don
would have been SoftSDV. Perhaps it was to work around a bug in
SoftSDV, though I suspect it's just as likely that the code came about
by a misunderstood/misdocumented PAL-requirement.
Perhaps Don or Asit remember how this came about?
I also cannot find a requirement that would demand allocating 96
stacked registers before making a PAL call and I'd be in favor of
cleaning that up.
--david
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Why large stack frame for PAL call
2004-06-27 17:42 Why large stack frame for PAL call Chen, Kenneth W
2004-06-29 5:50 ` David Mosberger
@ 2004-06-29 14:11 ` n0ano
2004-06-29 15:13 ` Chen, Kenneth W
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: n0ano @ 2004-06-29 14:11 UTC (permalink / raw)
To: linux-ia64
I can neither confirm nor deny these allegations (I think I've been
watching CSPAN too much :-)
I don't remember this code at all but my guess is that we did it
to be overly conservative about saving registers. Back then, especially
in a simulated environment, we didn't trust anything. As you say, most
likely we didn't trust PAL to save things properly so we made sure
it wouldn't be a problem.
If PAL doesn't touch the stack registers then it should be safe to
remove this.
On Mon, Jun 28, 2004 at 10:50:15PM -0700, David Mosberger wrote:
> >>>>> On Sun, 27 Jun 2004 10:42:14 -0700, "Chen, Kenneth W" <kenneth.w.chen@intel.com> said:
>
> Ken> Does anyone know why we need such large stack frame for PAL
> Ken> static call? PAL isn't even suppose to touch any stack
> Ken> register for static calling convention. Is it for legacy
> Ken> reason or something?
>
> Good question. I was able to track the source down to a patch that
> was sent to me by Walt Drummond on Aug 11, 1999. The authors listed
> in the relevant file (it was called palcall.S back then) were Don
> Dugger and Walt Drummond (in this order), so my guess is the code was
> originally written by Don. At that time, the primary target for Don
> would have been SoftSDV. Perhaps it was to work around a bug in
> SoftSDV, though I suspect it's just as likely that the code came about
> by a misunderstood/misdocumented PAL-requirement.
>
> Perhaps Don or Asit remember how this came about?
>
> I also cannot find a requirement that would demand allocating 96
> stacked registers before making a PAL call and I'd be in favor of
> cleaning that up.
>
> --david
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com
Ph: 303/447-2201
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: Why large stack frame for PAL call
2004-06-27 17:42 Why large stack frame for PAL call Chen, Kenneth W
2004-06-29 5:50 ` David Mosberger
2004-06-29 14:11 ` n0ano
@ 2004-06-29 15:13 ` Chen, Kenneth W
2004-06-29 16:20 ` Mallick, Asit K
2004-06-29 21:43 ` David Mosberger
4 siblings, 0 replies; 6+ messages in thread
From: Chen, Kenneth W @ 2004-06-29 15:13 UTC (permalink / raw)
To: linux-ia64
David Mosberger wrote on Monday, June 28, 2004 10:50 PM
>
> Ken> Does anyone know why we need such large stack frame for PAL
> Ken> static call? PAL isn't even suppose to touch any stack
> Ken> register for static calling convention. Is it for legacy
> Ken> reason or something?
>
> Good question. I was able to track the source down to a patch that
> was sent to me by Walt Drummond on Aug 11, 1999. The authors listed
> in the relevant file (it was called palcall.S back then) were Don
> Dugger and Walt Drummond (in this order), so my guess is the code was
> originally written by Don. At that time, the primary target for Don
> would have been SoftSDV. Perhaps it was to work around a bug in
> SoftSDV, though I suspect it's just as likely that the code came about
> by a misunderstood/misdocumented PAL-requirement.
>
> Perhaps Don or Asit remember how this came about?
>
> I also cannot find a requirement that would demand allocating 96
> stacked registers before making a PAL call and I'd be in favor of
> cleaning that up.
Checked with Asit. Yes, this was more of a conservative code just like
what Don said. Patch to clean it up.
--------
Clean up unnecessary large register stack frame for PAL static/stacked calls.
=== arch/ia64/kernel/pal.S 1.8 vs edited ==--- 1.8/arch/ia64/kernel/pal.S Mon Jun 28 22:07:49 2004
+++ edited/arch/ia64/kernel/pal.S Mon Jun 28 23:13:49 2004
@@ -55,7 +55,7 @@
*/
GLOBAL_ENTRY(ia64_pal_call_static)
.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(6)
- alloc loc1 = ar.pfs,6,90,0,0
+ alloc loc1 = ar.pfs,5,5,0,0
movl loc2 = pal_entry_point
1: {
mov r28 = in0
@@ -66,7 +66,9 @@
ld8 loc2 = [loc2] // loc2 <- entry point
tbit.nz p6,p7 = in4, 0
adds r8 = 1f-1b,r8
+ mov loc4=ar.rsc // save RSE configuration
;;
+ mov ar.rsc=0 // put RSE in enforced lazy, LE mode
mov loc3 = psr
mov loc0 = rp
.body
@@ -82,6 +84,7 @@
mov rp = r8
br.cond.sptk.many b7
1: mov psr.l = loc3
+ mov ar.rsc = loc4 // restore RSE configuration
mov ar.pfs = loc1
mov rp = loc0
;;
@@ -98,7 +101,7 @@
*/
GLOBAL_ENTRY(ia64_pal_call_stacked)
.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(5)
- alloc loc1 = ar.pfs,5,4,87,0
+ alloc loc1 = ar.pfs,4,4,4,0
movl loc2 = pal_entry_point
mov r28 = in0 // Index MUST be copied to r28
@@ -145,7 +148,7 @@
GLOBAL_ENTRY(ia64_pal_call_phys_static)
.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(6)
- alloc loc1 = ar.pfs,6,90,0,0
+ alloc loc1 = ar.pfs,4,7,0,0
movl loc2 = pal_entry_point
1: {
mov r28 = in0 // copy procedure index
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: Why large stack frame for PAL call
2004-06-27 17:42 Why large stack frame for PAL call Chen, Kenneth W
` (2 preceding siblings ...)
2004-06-29 15:13 ` Chen, Kenneth W
@ 2004-06-29 16:20 ` Mallick, Asit K
2004-06-29 21:43 ` David Mosberger
4 siblings, 0 replies; 6+ messages in thread
From: Mallick, Asit K @ 2004-06-29 16:20 UTC (permalink / raw)
To: linux-ia64
Chen, Kenneth W <> wrote on Tuesday, June 29, 2004 8:14 AM:
> David Mosberger wrote on Monday, June 28, 2004 10:50 PM
>>
>> Ken> Does anyone know why we need such large stack frame for PAL
>> Ken> static call? PAL isn't even suppose to touch any stack
>> Ken> register for static calling convention. Is it for legacy
Ken>
>> reason or something?
>>
>> Good question. I was able to track the source down to a patch that
>> was sent to me by Walt Drummond on Aug 11, 1999. The authors listed
>> in the relevant file (it was called palcall.S back then) were Don
>> Dugger and Walt Drummond (in this order), so my guess is the code was
>> originally written by Don. At that time, the primary target for Don
>> would have been SoftSDV. Perhaps it was to work around a bug in
>> SoftSDV, though I suspect it's just as likely that the code came
about
>> by a misunderstood/misdocumented PAL-requirement.
>>
>> Perhaps Don or Asit remember how this came about?
>>
>> I also cannot find a requirement that would demand allocating 96
>> stacked registers before making a PAL call and I'd be in favor of
>> cleaning that up.
>
> Checked with Asit. Yes, this was more of a conservative code just like
> what Don said. Patch to clean it up.
I rechecked some of my old documents and found that there was version of
the SDM that stated that the caller should ensure that all 96 stacked
registers are available before calling PAL procedure. However, this
restriction was removed in subsequent documents and is no longer needed.
The code did not get updated. So, Ken's patch should be fine.
Thanks,
Asit
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: Why large stack frame for PAL call
2004-06-27 17:42 Why large stack frame for PAL call Chen, Kenneth W
` (3 preceding siblings ...)
2004-06-29 16:20 ` Mallick, Asit K
@ 2004-06-29 21:43 ` David Mosberger
4 siblings, 0 replies; 6+ messages in thread
From: David Mosberger @ 2004-06-29 21:43 UTC (permalink / raw)
To: linux-ia64
>>>>> On Tue, 29 Jun 2004 09:20:49 -0700, "Mallick, Asit K" <asit.k.mallick@intel.com> said:
Asit> I rechecked some of my old documents and found that there was
Asit> version of the SDM that stated that the caller should ensure
Asit> that all 96 stacked registers are available before calling PAL
Asit> procedure.
Ah, that sounds vaguely familiar.
Asit> However, this restriction was removed in subsequent documents
Asit> and is no longer needed. The code did not get updated. So,
Asit> Ken's patch should be fine.
I guess we should try it on a Merced box, just to be reasonably sure.
I'll do that.
I guess this points out a weakness in the "checkstack" script: it
ought to add the space allocated by the "alloc" instructions as well.
Since the script is written in the wrong language (OK, at least the
language-name starts with "p", I'll give them credit for that ;-), I
won't try to fix this. Perhaps someone else wants to bite?
--david
^ permalink raw reply [flat|nested] 6+ messages in thread