invalidating I-cache on I-tanium

I've been writing some self-modifying Itanium assembly. Fun stuff if
you'd like to develope a deep routed psychosis. :)

Anyway, while my code does work, it should, to be proper, invalidate
the I-cache. I looked at the macro INSTRUCTION_MB and it contains:

.MACRO INSTRUCTION_MB address,length,?L1

.if ndf ALPHA
.if ndf IA64
.ERROR 0 ; No architecture defined
.endc
.endc

===> .if df ia64
===> .warn ; Not yet flushing the Icache
===> .endc

.IF NDF SMP$V_ENABLED
$SPLCODDEF
.ENDC
.WEAK SMP$GL_FLAGS
.WEAK SMP$INTALL_ACQ
.WEAK SMP$INTALL_BIT_ACQ
MOVAB SMP$GL_FLAGS,R0
BEQL L1
BBC #SMP$V_START_CPU, -
G^SMP$GL_FLAGS,L1
ASSUME SMP$V_ENABLED EQ 0
BLBC G^SMP$GL_FLAGS,L1
IPINT_ALL INV_ISTREAM
L1:
.if df alpha
EVAX_IMB
.endc


The .warn directive has me concerned. If "Not yet flushing the Icache",
why does the macro do an interprocessor interrupt? I'm hoping somebody
in VMS engineering is readign this and would answer.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

diy code:

.entry start,0

pushl #codelen
pushal addr
calls #2,g^sys$pal_imb
ret

codestart=.

addr: .jsb_entry
rsb

codelen=.-codestart

.end start

Jur.


VAXman- @SendSpamHere.ORG wrote, On 13-8-2008 16:59:[color=blue]
> I've been writing some self-modifying Itanium assembly. Fun stuff if
> you'd like to develope a deep routed psychosis. :)
>
> Anyway, while my code does work, it should, to be proper, invalidate
> the I-cache. I looked at the macro INSTRUCTION_MB and it contains:
>
> .MACRO INSTRUCTION_MB address,length,?L1
>
> .if ndf ALPHA
> .if ndf IA64
> .ERROR 0 ; No architecture defined
> .endc
> .endc
>
> ===> .if df ia64
> ===> .warn ; Not yet flushing the Icache
> ===> .endc
>
> .IF NDF SMP$V_ENABLED
> $SPLCODDEF
> .ENDC
> .WEAK SMP$GL_FLAGS
> .WEAK SMP$INTALL_ACQ
> .WEAK SMP$INTALL_BIT_ACQ
> MOVAB SMP$GL_FLAGS,R0
> BEQL L1
> BBC #SMP$V_START_CPU, -
> G^SMP$GL_FLAGS,L1
> ASSUME SMP$V_ENABLED EQ 0
> BLBC G^SMP$GL_FLAGS,L1
> IPINT_ALL INV_ISTREAM
> L1:
> .if df alpha
> EVAX_IMB
> .endc
>
>
> The .warn directive has me concerned. If "Not yet flushing the Icache",
> why does the macro do an interprocessor interrupt? I'm hoping somebody
> in VMS engineering is readign this and would answer.
>[/color]

In article <48a938df$0$185$e4fe514c@news.xs4all.nl>, Jur van der Burg <"lddriver at digiater dot nl"> writes:[color=blue]
>diy code:
>
> .entry start,0
>
> pushl #codelen
> pushal addr
> calls #2,g^sys$pal_imb
> ret
>
>codestart=.
>
>addr: .jsb_entry
> rsb
>
>codelen=.-codestart
>
> .end start
>
>Jur.[/color]

Thanks Jur. This I know. My question was ABOUT the comment in the
INSTRUCTION_MB macro. Also, for what I'm doing (modifying executive
code) the I-cache should be invalidated on all participating CPUs;
thus, implying, the interprocessor interrupt. ;)

Strangely, there are defs in BLISS and C libraries but not in Macro.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Fwiw, sys$pal_imb does this for all cpu's.

The lack of support in macro is probably an oversight.

Jur.

VAXman- @SendSpamHere.ORG wrote, On 18-8-2008 14:39:[color=blue]
> In article <48a938df$0$185$e4fe514c@news.xs4all.nl>, Jur van der Burg <"lddriver at digiater dot nl"> writes:[color=green]
>> diy code:
>>
>> .entry start,0
>>
>> pushl #codelen
>> pushal addr
>> calls #2,g^sys$pal_imb
>> ret
>>
>> codestart=.
>>
>> addr: .jsb_entry
>> rsb
>>
>> codelen=.-codestart
>>
>> .end start
>>
>> Jur.[/color]
>
> Thanks Jur. This I know. My question was ABOUT the comment in the
> INSTRUCTION_MB macro. Also, for what I'm doing (modifying executive
> code) the I-cache should be invalidated on all participating CPUs;
> thus, implying, the interprocessor interrupt. ;)
>
> Strangely, there are defs in BLISS and C libraries but not in Macro.
>[/color]

On I64, there is an EVAX_IMB macro inside of STARLET.MLB that will do the
right thing. You can just say

EVAX_IMB

on both Alpha and I64 and the correct code will come out.

As for the INSTRUCTION_MB macro, I found some confusing comments, but I
think that it is Alpha only. It seems like IA64 work was started on the
macro, but it was never finished. Looking at one use, I see it
conditionalized for Alpha only. The else path for I64 has an explicit CALLS
to a routine named MMG$INSTRUCTION_MB. Why couldn't INSTRUCTION_MB be
changed to just call MMG$INSTRUCTION_MB? Beats me. I didn't write it.

John

"Jur van der Burg" <"lddriver at digiater dot nl"> wrote in message
news:48a938df$0$185$e4fe514c@news.xs4all.nl...[color=blue]
> diy code:
>
> .entry start,0
>
> pushl #codelen
> pushal addr
> calls #2,g^sys$pal_imb
> ret
>
> codestart=.
>
> addr: .jsb_entry
> rsb
>
> codelen=.-codestart
>
> .end start
>
> Jur.
>
>
> VAXman- @SendSpamHere.ORG wrote, On 13-8-2008 16:59:[color=green]
>> I've been writing some self-modifying Itanium assembly. Fun stuff if
>> you'd like to develope a deep routed psychosis. :) Anyway, while my code
>> does work, it should, to be proper, invalidate
>> the I-cache. I looked at the macro INSTRUCTION_MB and it contains:
>>
>> .MACRO INSTRUCTION_MB address,length,?L1
>>
>> .if ndf ALPHA
>> .if ndf IA64
>> .ERROR 0 ; No architecture defined
>> .endc
>> .endc
>>
>> ===> .if df ia64
>> ===> .warn ; Not yet flushing the Icache
>> ===> .endc
>>
>> .IF NDF SMP$V_ENABLED
>> $SPLCODDEF
>> .ENDC
>> .WEAK SMP$GL_FLAGS
>> .WEAK SMP$INTALL_ACQ
>> .WEAK SMP$INTALL_BIT_ACQ
>> MOVAB SMP$GL_FLAGS,R0
>> BEQL L1
>> BBC #SMP$V_START_CPU, -
>> G^SMP$GL_FLAGS,L1
>> ASSUME SMP$V_ENABLED EQ 0
>> BLBC G^SMP$GL_FLAGS,L1
>> IPINT_ALL INV_ISTREAM
>> L1:
>> .if df alpha
>> EVAX_IMB
>> .endc
>> The .warn directive has me concerned. If "Not yet flushing the Icache",
>> why does the macro do an interprocessor interrupt? I'm hoping somebody
>> in VMS engineering is readign this and would answer.
>>[/color][/color]

In article <rfqdnc6Ivf2FuDHVnZ2dnUVZ_uOdnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:[color=blue]
>On I64, there is an EVAX_IMB macro inside of STARLET.MLB that will do the
>right thing. You can just say
>
>EVAX_IMB
>
>on both Alpha and I64 and the correct code will come out.[/color]

Thanks John, save that EVAX_IMB takes arguments on IA64. I have EVAX_IMB
in a great deal of Alpha code. I now will need to specify an address and
the length of the code address region to invalidate with the EVAX_IMB.



[color=blue]
>As for the INSTRUCTION_MB macro, I found some confusing comments, but I
>think that it is Alpha only. It seems like IA64 work was started on the
>macro, but it was never finished. Looking at one use, I see it
>conditionalized for Alpha only. The else path for I64 has an explicit CALLS
>to a routine named MMG$INSTRUCTION_MB. Why couldn't INSTRUCTION_MB be
>changed to just call MMG$INSTRUCTION_MB? Beats me. I didn't write it.[/color]

OK. Looks like somebody thought about INSTRUCTION_MB but never went back
to it.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.