Why large stack frame for PAL call

Why large stack frame for PAL call

[Chen, Kenneth W]

Does anyone know why we need such large stack frame for PAL static
call?  PAL isn't even suppose to touch any stack register for static
calling convention.  Is it for legacy reason or something?

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

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

96 local registers?

Also caller is support to setup callee's stack frame for PAL stacked
convention?  Wasn't clear from the PAL spec.  Though I couldn't make
up any story why it needs to.

Re: Why large stack frame for PAL call

[David Mosberger]

>>>>> 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

Re: Why large stack frame for PAL call

[n0ano]

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

RE: Why large stack frame for PAL call

[Chen, Kenneth W]

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

RE: Why large stack frame for PAL call

[Mallick, Asit K]

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

RE: Why large stack frame for PAL call

[David Mosberger]

>>>>> 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