I have not had much contact with Itanium due to the lack of PLI and
compatible Ada compilers.  But I (naively) told someone their Alpha
C program would be "compile-and-link" on Itanium and she could keep
her VAX behavior with compatible source between Alpha and Itanium.

Now when I try HP C V7.2-022 on OpenVMS IA64 V8.3, I get:

> cc/standard=vaxc/extern=strict/nomember_alignment/debug/nooptimize/list=DISK$USER:[KILGALLEN.TEST.LIS]/show=include/float=d_float MATH.C
> 
>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);
> .......................^
> %CC-E-BIFNOTAVAIL, Built-in function __DIVG_C is not available on this platform.
> at line number 1872 in file DISK$USER:[KILGALLEN.TEST.SRC]MATH.C;1
> %MMS-F-ABORT, For target MATH.OBJ, CLI returned abort status: %X10B91262

What is the replacement technique for __DIVG_C on Itanium ?

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:LkYWkZCqZrm8@eisner.encompasserve.org...
>I have not had much contact with Itanium due to the lack of PLI and
> compatible Ada compilers.  But I (naively) told someone their Alpha
> C program would be "compile-and-link" on Itanium and she could keep
> her VAX behavior with compatible source between Alpha and Itanium.
>
> Now when I try HP C V7.2-022 on OpenVMS IA64 V8.3, I get:
>
>> cc/standard=vaxc/extern=strict/nomember_alignment/debug/nooptimize/list=DISK$USER:[KILGALLEN.TEST.LIS]/show=include/float=d_float 
>> MATH.C
>>
>>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);
>> .......................^
>> %CC-E-BIFNOTAVAIL, Built-in function __DIVG_C is not available on this 
>> platform.
>> at line number 1872 in file DISK$USER:[KILGALLEN.TEST.SRC]MATH.C;1
>> %MMS-F-ABORT, For target MATH.OBJ, CLI returned abort status: %X10B91262
>
> What is the replacement technique for __DIVG_C on Itanium ?

The documentation all seems to indicate that it is still there...  but 
perhaps it is because you are doing a divide G chopped and compiling with 
D_FLOAT?

In article <f3jrui$pr4$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
> news:LkYWkZCqZrm8@eisner.encompasserve.org...
>>I have not had much contact with Itanium due to the lack of PLI and
>> compatible Ada compilers.  But I (naively) told someone their Alpha
>> C program would be "compile-and-link" on Itanium and she could keep
>> her VAX behavior with compatible source between Alpha and Itanium.
>>
>> Now when I try HP C V7.2-022 on OpenVMS IA64 V8.3, I get:
>>
>>> cc/standard=vaxc/extern=strict/nomember_alignment/debug/nooptimize/list=DISK$USER:[KILGALLEN.TEST.LIS]/show=include/float=d_float 
>>> MATH.C
>>>
>>>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);
>>> .......................^
>>> %CC-E-BIFNOTAVAIL, Built-in function __DIVG_C is not available on this 
>>> platform.
>>> at line number 1872 in file DISK$USER:[KILGALLEN.TEST.SRC]MATH.C;1
>>> %MMS-F-ABORT, For target MATH.OBJ, CLI returned abort status: %X10B91262
>>
>> What is the replacement technique for __DIVG_C on Itanium ?
> 
> The documentation all seems to indicate that it is still there...  but 
> perhaps it is because you are doing a divide G chopped and compiling with 
> D_FLOAT?

Thanks for the suggestion, but when I switch that /float=d_float
to /float=g_float, I get the same compilation error.

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:s6+0wmajSvK9@eisner.encompasserve.org...
> In article <f3jrui$pr4$1@usenet01.boi.hp.com>, "FredK" 
> <fred.nospam@dec.com> writes:
>>
>> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>> news:LkYWkZCqZrm8@eisner.encompasserve.org...
>>>I have not had much contact with Itanium due to the lack of PLI and
>>> compatible Ada compilers.  But I (naively) told someone their Alpha
>>> C program would be "compile-and-link" on Itanium and she could keep
>>> her VAX behavior with compatible source between Alpha and Itanium.
>>>
>>> Now when I try HP C V7.2-022 on OpenVMS IA64 V8.3, I get:
>>>
>>>> cc/standard=vaxc/extern=strict/nomember_alignment/debug/nooptimize/list=DISK$USER:[KILGALLEN.TEST.LIS]/show=include/float=d_float
>>>> MATH.C
>>>>
>>>>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);
>>>> .......................^
>>>> %CC-E-BIFNOTAVAIL, Built-in function __DIVG_C is not available on this
>>>> platform.
>>>> at line number 1872 in file DISK$USER:[KILGALLEN.TEST.SRC]MATH.C;1
>>>> %MMS-F-ABORT, For target MATH.OBJ, CLI returned abort status: 
>>>> %X10B91262
>>>
>>> What is the replacement technique for __DIVG_C on Itanium ?
>>
>> The documentation all seems to indicate that it is still there...  but
>> perhaps it is because you are doing a divide G chopped and compiling with
>> D_FLOAT?
>
> Thanks for the suggestion, but when I switch that /float=d_float
> to /float=g_float, I get the same compilation error.

What does /warn=enable=verbose  tell you?

I searched the DECC notes and don't see anything about it not being 
available... maybe the error itself might be expanded.

In article <f3k0r5$umc$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
> news:s6+0wmajSvK9@eisner.encompasserve.org...
>> In article <f3jrui$pr4$1@usenet01.boi.hp.com>, "FredK" 
>> <fred.nospam@dec.com> writes:
>>>
>>> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>>> news:LkYWkZCqZrm8@eisner.encompasserve.org...
>>>>I have not had much contact with Itanium due to the lack of PLI and
>>>> compatible Ada compilers.  But I (naively) told someone their Alpha
>>>> C program would be "compile-and-link" on Itanium and she could keep
>>>> her VAX behavior with compatible source between Alpha and Itanium.
>>>>
>>>> Now when I try HP C V7.2-022 on OpenVMS IA64 V8.3, I get:
>>>>
>>>>> cc/standard=vaxc/extern=strict/nomember_alignment/debug/nooptimize/list=DISK$USER:[KILGALLEN.TEST.LIS]/show=include/float=d_float
>>>>> MATH.C
>>>>>
>>>>>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);
>>>>> .......................^
>>>>> %CC-E-BIFNOTAVAIL, Built-in function __DIVG_C is not available on this
>>>>> platform.
>>>>> at line number 1872 in file DISK$USER:[KILGALLEN.TEST.SRC]MATH.C;1
>>>>> %MMS-F-ABORT, For target MATH.OBJ, CLI returned abort status: 
>>>>> %X10B91262
>>>>
>>>> What is the replacement technique for __DIVG_C on Itanium ?
>>>
>>> The documentation all seems to indicate that it is still there...  but
>>> perhaps it is because you are doing a divide G chopped and compiling with
>>> D_FLOAT?
>>
>> Thanks for the suggestion, but when I switch that /float=d_float
>> to /float=g_float, I get the same compilation error.
> 
> What does /warn=enable=verbose  tell you?


%CC-W-UNKMSGID, Unknown message id or group "VERBOSE" is ignored.

:-)

but /warn=verbose adds

Description: This Alpha built-in function is not available on the IA64 platform.
 
User Action: See documentation for alternatives. 

> I searched the DECC notes and don't see anything about it not being 
> available... maybe the error itself might be expanded.

Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by

	http://h71000.www7.hp.com/commercial/c/index_I64.html

specifically says __DIVG_C exists.

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>
> Description: This Alpha built-in function is not available on the IA64 
> platform.
>
> User Action: See documentation for alternatives.
>
>> I searched the DECC notes and don't see anything about it not being
>> available... maybe the error itself might be expanded.
>
> Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by
>
> http://h71000.www7.hp.com/commercial/c/index_I64.html
>
> specifically says __DIVG_C exists.

I posted the question in the internal DECC notesfile, I'll let you know what 
I hear.

In article <f3k43h$1gp$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>>
>> Description: This Alpha built-in function is not available on the IA64 
>> platform.
>>
>> User Action: See documentation for alternatives.
>>
>>> I searched the DECC notes and don't see anything about it not being
>>> available... maybe the error itself might be expanded.
>>
>> Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by
>>
>> http://h71000.www7.hp.com/commercial/c/index_I64.html
>>
>> specifically says __DIVG_C exists.
> 
> I posted the question in the internal DECC notesfile, I'll let you know what 
> I hear.

Thanks, Fred.

Larry Kilgallen wrote:
> 
> In article <f3k43h$1gp$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:
> > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> >>
> >> Description: This Alpha built-in function is not available on the IA64
> >> platform.
> >>
> >> User Action: See documentation for alternatives.
> >>
> >>> I searched the DECC notes and don't see anything about it not being
> >>> available... maybe the error itself might be expanded.
> >>
> >> Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by
> >>
> >> http://h71000.www7.hp.com/commercial/c/index_I64.html
> >>
> >> specifically says __DIVG_C exists.
> >
> > I posted the question in the internal DECC notesfile, I'll let you know what
> > I hear.
> 
> Thanks, Fred.

Dumb question time: is this being pursued through formal support channels (ITRC,
etc.)? At least then it might appear in the database that the trained
apes^H^H^H^H^H^H^H^H^H^H^H^H outsourced call-takers use.

-- 
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

"David J Dachtera" <djesys.no@spam.comcast.net> wrote in message 
news:465DACF2.354FD05C@spam.comcast.net...
> Larry Kilgallen wrote:
>>
>> In article <f3k43h$1gp$1@usenet01.boi.hp.com>, "FredK" 
>> <fred.nospam@dec.com> writes:
>> > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>> >>
>> >> Description: This Alpha built-in function is not available on the IA64
>> >> platform.
>> >>
>> >> User Action: See documentation for alternatives.
>> >>
>> >>> I searched the DECC notes and don't see anything about it not being
>> >>> available... maybe the error itself might be expanded.
>> >>
>> >> Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by
>> >>
>> >> http://h71000.www7.hp.com/commercial/c/index_I64.html
>> >>
>> >> specifically says __DIVG_C exists.
>> >
>> > I posted the question in the internal DECC notesfile, I'll let you know 
>> > what
>> > I hear.
>>
>> Thanks, Fred.
>
> Dumb question time: is this being pursued through formal support channels 
> (ITRC,
> etc.)? At least then it might appear in the database that the trained
> apes^H^H^H^H^H^H^H^H^H^H^H^H outsourced call-takers use.
>

Nope.

The first question is if this is a cockpit error of some sort by Larry. 
There may be some simple-stupid thing that he isn't doing.

I am asking the question in an internal forum where I will get an answer... 
IF the answer is that there is a bug or a documentation error - I will ask 
Larry or his customer to report it through the normal channels.  I tend to 
believe at this point that whatever the answer is - we have a problem since 
there is no information anyplace that this should not work - or that you 
need to do anything special.

People (like some guy named Richard) seem to think that we don't actually 
look at or fix problems that do not come through the normal bug reporting 
channels...  this isn't true - it is hit-or-miss in terms of someone paying 
attention and seeing it in a non-conventional forum.  However, the way you 
ensure that you get the ECO into the version you need it in - is by making 
sure it is logged in the normal manner.

Larry Kilgallen wrote:
> C program would be "compile-and-link" on Itanium and she could keep
> her VAX behavior with compatible source between Alpha and Itanium.

Does IA64's floating point implementation differ significantly from 
Alpha and VAX since it only has IEEE support in the architecture ?

>>          dfloat_temp = __DIVG_C(dfloat_temp, gfloat_ten);

Out of curiosity, is there on-line doc for __DIVG_C ? (help <mumble> 
<mulble> ?)

If there is no hardware support for either floating point types, perhaps 
those macros are not supported on iA64 since they would require totally 
different code ?

JF Mezei wrote:

> 
> Does IA64's floating point implementation differ significantly from 
> Alpha and VAX since it only has IEEE support in the architecture ?
> 

Yes.  The default is on OpenVMS I64 is IEEE floating (S_floating, 
T_floating, X_floating for single, double, quad respectively) where it 
is VAX on ALpha (F_floating, G_floating, X_floating).

However, the compilers on I64 have the optional ability to provide VAX 
floating support by converting to/from IEEE for the operations needed 
(with appropriate caveats for the many edge conditions).

So for MOST programs that use floating point, it should be 
recompile-&-go, but some that rely on specific formats or even specific 
rounding modes available on Alpha, recoding would be necessary.

-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:k0W31rHXQVan@eisner.encompasserve.org...
>
>> I searched the DECC notes and don't see anything about it not being
>> available... maybe the error itself might be expanded.
>
> Section 6.2.1.3 on page 6-32 (354) of the User Guide pointed to by
>
> http://h71000.www7.hp.com/commercial/c/index_I64.html
>
> specifically says __DIVG_C exists.

    Larry,

    Section 6.2.1.3 is part of section 6.2.1 which describes *Alpha* BIFs
    Section 6.2.2 is for BIF's on Integrity.

    Here is my reply to Fred's posting in our notes file:


    Fred,

    From the C Release Notes:

        3.2 Builtin Functions

        3.2.1 Alpha compatibility

              The philosophy for the builtin functions is that most
              any existing uses of Alpha builtins should continue to
              work under IA64 where possible, but that the compiler
              will issue diagnostics where it would be preferable to
              use a different builtin for IA64. For this reason, the
              builtins.h header has not removed or conditionalized
              out any of the Alpha declarations. Instead, it contains
              comments noting which ones are not available or not the
              preferred form for IA64.

    If you look at builtins.h you'll see:

/*
**  Divide Floating Point Chopped
**  Note: Not on ia64
*/
float  __DIVF_C(float  __operand1, float  __operand2);
double __DIVG_C(double __operand1, double __operand2);


    So...the BIF is not available on Integrity.

    Ed Vogel
    HP/Compaq/DEC C/C++ Engineering

In article <f3kp7r$k8v$1@usenet01.boi.hp.com>, "Ed Vogel" <edward.vogel@stopppingspam.hp.com> writes:

>         3.2.1 Alpha compatibility
> 
>               The philosophy for the builtin functions is that most
>               any existing uses of Alpha builtins should continue to
>               work under IA64 where possible, but that the compiler
>               will issue diagnostics where it would be preferable to
>               use a different builtin for IA64. For this reason, the
>               builtins.h header has not removed or conditionalized
>               out any of the Alpha declarations. Instead, it contains
>               comments noting which ones are not available or not the
>               preferred form for IA64.
> 
>     If you look at builtins.h you'll see:
> 
> /*
> **  Divide Floating Point Chopped
> **  Note: Not on ia64
> */
> float  __DIVF_C(float  __operand1, float  __operand2);
> double __DIVG_C(double __operand1, double __operand2);
> 
> 
>     So...the BIF is not available on Integrity.

Thanks for verifying that the compiler behavior is intentional.
My problem with this code (which I don't know much about, not
being the author, a Math person or a C person) is what I should
use in place of this on IA64. Or is there a class of C programs
(like PL/I and Ada) that are just supposed to stay on Alpha and VAX ?

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:5eoUb+1DEiJ$@eisner.encompasserve.org...
>
> Thanks for verifying that the compiler behavior is intentional.
> My problem with this code (which I don't know much about, not
> being the author, a Math person or a C person) is what I should
> use in place of this on IA64. Or is there a class of C programs
> (like PL/I and Ada) that are just supposed to stay on Alpha and VAX ?

    Larry,

    I'm afraid I can't help here.  I'm also not a math person!

    Ed

Ed Vogel wrote:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
> news:5eoUb+1DEiJ$@eisner.encompasserve.org...
> 
>>Thanks for verifying that the compiler behavior is intentional.
>>My problem with this code (which I don't know much about, not
>>being the author, a Math person or a C person) is what I should
>>use in place of this on IA64. Or is there a class of C programs
>>(like PL/I and Ada) that are just supposed to stay on Alpha and VAX ?
> 
> 
>     Larry,
> 
>     I'm afraid I can't help here.  I'm also not a math person!
> 
>     Ed
> 
> 

Neither am I, but here goes... :-)

I'll assuming that the original author of the algorithm decided that 
[s]he wanted a chopped division for this single operation and instead of 
placing it inside its own module compiled with /ROUNDING_MODE=CHOPPED, 
[s]he just used the __DIVG_C builtin to get the DIVG/C instruction.

On Itanium, the rounding modes are not encoded in the instruction but 
are inside the floating point control register.

If you want a chopped operation independent of the other operations, you 
need to call the SYS$IEEE_SET_ROUNDING_MODE service (available on I64 
only).  It is in the manuals.  Don't forget to put the prior value back.

As for why chopped or if you can do without it, that would be a function 
of the algorithm.

-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

In article <f3mi0o$7dg$1@usenet01.boi.hp.com>, John Reagan <john.reagan@hp.com> writes:
> Ed Vogel wrote:
>> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
>> news:5eoUb+1DEiJ$@eisner.encompasserve.org...
>> 
>>>Thanks for verifying that the compiler behavior is intentional.
>>>My problem with this code (which I don't know much about, not
>>>being the author, a Math person or a C person) is what I should
>>>use in place of this on IA64. Or is there a class of C programs
>>>(like PL/I and Ada) that are just supposed to stay on Alpha and VAX ?
>> 
>> 
>>     Larry,
>> 
>>     I'm afraid I can't help here.  I'm also not a math person!
>> 
>>     Ed
>> 
>> 
> 
> Neither am I, but here goes... :-)
> 
> I'll assuming that the original author of the algorithm decided that 
> [s]he wanted a chopped division for this single operation and instead of 
> placing it inside its own module compiled with /ROUNDING_MODE=CHOPPED, 
> [s]he just used the __DIVG_C builtin to get the DIVG/C instruction.

Thanks, John.  I am enough of a non-expert to not know about the
/ROUNDING_MODE=CHOPPED.  Perhaps creating a new module would be
the best way to have common source between Alpha and IPF.

> On Itanium, the rounding modes are not encoded in the instruction but 
> are inside the floating point control register.
> 
> If you want a chopped operation independent of the other operations, you 
> need to call the SYS$IEEE_SET_ROUNDING_MODE service (available on I64 
> only).  It is in the manuals.  Don't forget to put the prior value back.
> 
> As for why chopped or if you can do without it, that would be a function 
> of the algorithm.
> 
> -- 
> John Reagan
> OpenVMS Pascal/Macro-32/COBOL Project Leader
> Hewlett-Packard Company

Larry Kilgallen wrote:

> 
> 
> Thanks, John.  I am enough of a non-expert to not know about the
> /ROUNDING_MODE=CHOPPED.  Perhaps creating a new module would be
> the best way to have common source between Alpha and IPF.
> 

Well, there will be some conditionalization in any case.

As I mentioned, on Alpha each module can have its own /ROUNDING_MODE 
setting and those rounding modes are encoded directly into each 
instruction.  Multiple modes can co-exist in a single application 
without any additional overhead.

On Itanium, there is one "global" setting in the FPCR (floating point 
control register) [there is actually more than one, but that isn't 
relevant to this discussion since the generated code only uses one of 
them].  We couldn't implement it like we do on Alpha.

So each module records its "preferred" floating settings (VAX vs IEEE, 
precision, rounding-mode) in the object file.  The linker uses the 
floating settings from the module with the main entry point as the 
"whole program" setting.  This is recorded in the .EXE and is used by 
the image activator prior to the start of your program.  We did this so 
things like LIB$INITIALIZE routines, AST routines, etc. can all have 
consistent floating settings.  You wouldn't want your timer AST routine 
to have different settings depending on which piece of code was 
interrupted by the timer AST, right?

What this means is that for modules that don't contain the main entry 
point, the settings of /ROUNDING_MODE and /IEEE_MODE are essentially 
worthless on I64.  We didn't want to start automatically inserting calls 
to SYS$IEEE_SET_FP_xxx into every single routine since most people don't 
do this style of coding.  C does provide /CHECK=FP_MODE to check that 
the floating settings at run-time match the /ROUNDING_MODE and 
/IEEE_MODE set at compile-time.  You have to insert calls to 
SYS$IEEE_SET_FP_xxx into your code to set the settings to your liking, 
do the operation(s) desired, and set them back.  You also can't use 
/CHECK=FP_MODE anymore since that check is performed in the routine 
prolog BEFORE you get a chance to change the settings via 
SYS$IEEE_SET_FP_xxx.

So you can conditionalize the current code:

#if alpha
   - use __DIVG_C
#endif
#if i64
   - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
   - use the regular division operator
   - restore prior rounding mode
#endif

or if you make a separate module that is compiled with 
/ROUNDING=CHOPPED, you still have

#if i64
   - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
#endif
- use the regular division operator
#if i64
   - restore prior rounding mode
#endif



-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

Hi John,

Why can't they all be like you?

Cheers Richard Maher

PS. Your going into bat for the caller's mode heap manager was invaluable.

"John Reagan" <john.reagan@hp.com> wrote in message
news:f3ngoc$3sr$1@usenet01.boi.hp.com...
> Larry Kilgallen wrote:
>
> >
> >
> > Thanks, John.  I am enough of a non-expert to not know about the
> > /ROUNDING_MODE=CHOPPED.  Perhaps creating a new module would be
> > the best way to have common source between Alpha and IPF.
> >
>
> Well, there will be some conditionalization in any case.
>
> As I mentioned, on Alpha each module can have its own /ROUNDING_MODE
> setting and those rounding modes are encoded directly into each
> instruction.  Multiple modes can co-exist in a single application
> without any additional overhead.
>
> On Itanium, there is one "global" setting in the FPCR (floating point
> control register) [there is actually more than one, but that isn't
> relevant to this discussion since the generated code only uses one of
> them].  We couldn't implement it like we do on Alpha.
>
> So each module records its "preferred" floating settings (VAX vs IEEE,
> precision, rounding-mode) in the object file.  The linker uses the
> floating settings from the module with the main entry point as the
> "whole program" setting.  This is recorded in the .EXE and is used by
> the image activator prior to the start of your program.  We did this so
> things like LIB$INITIALIZE routines, AST routines, etc. can all have
> consistent floating settings.  You wouldn't want your timer AST routine
> to have different settings depending on which piece of code was
> interrupted by the timer AST, right?
>
> What this means is that for modules that don't contain the main entry
> point, the settings of /ROUNDING_MODE and /IEEE_MODE are essentially
> worthless on I64.  We didn't want to start automatically inserting calls
> to SYS$IEEE_SET_FP_xxx into every single routine since most people don't
> do this style of coding.  C does provide /CHECK=FP_MODE to check that
> the floating settings at run-time match the /ROUNDING_MODE and
> /IEEE_MODE set at compile-time.  You have to insert calls to
> SYS$IEEE_SET_FP_xxx into your code to set the settings to your liking,
> do the operation(s) desired, and set them back.  You also can't use
> /CHECK=FP_MODE anymore since that check is performed in the routine
> prolog BEFORE you get a chance to change the settings via
> SYS$IEEE_SET_FP_xxx.
>
> So you can conditionalize the current code:
>
> #if alpha
>    - use __DIVG_C
> #endif
> #if i64
>    - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
>    - use the regular division operator
>    - restore prior rounding mode
> #endif
>
> or if you make a separate module that is compiled with
> /ROUNDING=CHOPPED, you still have
>
> #if i64
>    - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
> #endif
> - use the regular division operator
> #if i64
>    - restore prior rounding mode
> #endif
>
>
>
> -- 
> John Reagan
> OpenVMS Pascal/Macro-32/COBOL Project Leader
> Hewlett-Packard Company

"John Reagan" <john.reagan@hp.com> wrote in message 
news:f3mi0o$7dg$1@usenet01.boi.hp.com...

> I'll assuming that the original author of the algorithm decided that [s]he wanted a 
> chopped division for this single operation and instead of placing it inside its own 
> module compiled with /ROUNDING_MODE=CHOPPED, [s]he just used the __DIVG_C builtin to get 
> the DIVG/C instruction.

It also appears to be using a G_FLOAT divide when the rest of the module
is D_FLOAT. If that was intentional, maybe the rounding mode isn't so
critical and any DIVG would do. 

John Reagan wrote:

....

> 
> On Itanium, there is one "global" setting in the FPCR (floating point 
> control register) [there is actually more than one, but that isn't 
> relevant to this discussion since the generated code only uses one of 
> them].  We couldn't implement it like we do on Alpha.
> 
> So each module records its "preferred" floating settings (VAX vs IEEE, 
> precision, rounding-mode) in the object file.  The linker uses the 
> floating settings from the module with the main entry point as the 
> "whole program" setting.  This is recorded in the .EXE and is used by 
> the image activator prior to the start of your program.  We did this so 
> things like LIB$INITIALIZE routines, AST routines, etc. can all have 
> consistent floating settings.  You wouldn't want your timer AST routine 
> to have different settings depending on which piece of code was 
> interrupted by the timer AST, right?

Thanks for this good explanation :-) I was always wondering why it would 
be impossible to have modules compiled with different floating point 
mode working as expected (as on Alpha) on Itanium.

> So you can conditionalize the current code:
> 
> #if alpha
>   - use __DIVG_C
> #endif
> #if i64
>   - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
>   - use the regular division operator
>   - restore prior rounding mode
> #endif

What about disabling AST's? Wouldn't that be necessary, according
to your writing above?

Albrecht

In article <f3oq5o$9oq$1@south.jnrs.ja.net>, "Richard Brodie" <R.Brodie@rl.ac.uk> writes:
> 
> "John Reagan" <john.reagan@hp.com> wrote in message 
> news:f3mi0o$7dg$1@usenet01.boi.hp.com...
> 
>> I'll assuming that the original author of the algorithm decided that [s]he wanted a 
>> chopped division for this single operation and instead of placing it inside its own 
>> module compiled with /ROUNDING_MODE=CHOPPED, [s]he just used the __DIVG_C builtin to get 
>> the DIVG/C instruction.
> 
> It also appears to be using a G_FLOAT divide when the rest of the module
> is D_FLOAT. If that was intentional, maybe the rounding mode isn't so
> critical and any DIVG would do. 

Appearances from the peephole view can be deceiving.  The code uses
particular variables one time for one type of float and another time
for another type.

But thanks for pointing that out.

Albrecht Schlosser wrote:
> John Reagan wrote:

>> So you can conditionalize the current code:
>>
>> #if alpha
>>   - use __DIVG_C
>> #endif
>> #if i64
>>   - call SYS$IEEE_SET_FP_ROUNDING_MODE to truncate (ie chopped)
>>   - use the regular division operator
>>   - restore prior rounding mode
>> #endif
> 
> 
> What about disabling AST's? Wouldn't that be necessary, according
> to your writing above?
> 
> Albrecht

The AST's floating settings always come from the image's default 
settings.  The fact that you've went from 'something' to TRUNCATE and 
back to 'something' won't be noticed by any AST that might fire in the 
window.  SYS$IEEE_SET_FP_ROUNDING_MODE doesn't change the default.

However, you might have to consider the situation where you get an 
exception (say, divide by zero) and then want to $UNWIND in a handler. 
Since the UNWIND would skip the "restore prior rounding mode", the 
handler would have to do that if needed.  The floating settings aren't 
part of the restored register set that $UNWIND and friends work with.


-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

Richard Maher wrote:
> Hi John,
> 
> Why can't they all be like you?
> 

I don't think my group could tolerate more than one of me.  :-)


-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

I cannot find

	SYS$IEEE_SET_FP_ROUNDING_MODE

in the VMS V8.3

	System Services Reference Manual
	Release Notes
	New Features and Documentation Overview

Where do we get a description ?

Or is it unsupported for customer use ?

In article <RdSlawcyZ$5X@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> I cannot find
> 
> 	SYS$IEEE_SET_FP_ROUNDING_MODE
> 
> in the VMS V8.3
> 
> 	System Services Reference Manual
> 	Release Notes
> 	New Features and Documentation Overview

It has been pointed out to me that the actual spelling is

	SYS$$IEEE_SET_ROUNDING_MODE

and indeed that is in the system services reference manual.

Larry Kilgallen wrote:
> In article <RdSlawcyZ$5X@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>>I cannot find
>>
>>	SYS$IEEE_SET_FP_ROUNDING_MODE
>>
>>in the VMS V8.3
>>
>>	System Services Reference Manual
>>	Release Notes
>>	New Features and Documentation Overview
> 
> 
> It has been pointed out to me that the actual spelling is
> 
> 	SYS$$IEEE_SET_ROUNDING_MODE
> 
> and indeed that is in the system services reference manual.

ooops my bad.

For those of you keeping score at home, the three services are:

SYS$IEEE_SET_FP_CONTROL
SYS$IEEE_SET_PRECISION_MODE
SYS$IEEE_SET_ROUNDING_MODE

All documented and supported.

-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

John Reagan wrote:
> 
> Larry Kilgallen wrote:
> > In article <RdSlawcyZ$5X@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> >
> >>I cannot find
> >>
> >>      SYS$IEEE_SET_FP_ROUNDING_MODE
> >>
> >>in the VMS V8.3
> >>
> >>      System Services Reference Manual
> >>      Release Notes
> >>      New Features and Documentation Overview
> >
> >
> > It has been pointed out to me that the actual spelling is
> >
> >       SYS$$IEEE_SET_ROUNDING_MODE
> >
> > and indeed that is in the system services reference manual.
> 
> ooops my bad.
> 
> For those of you keeping score at home, the three services are:
> 
> SYS$IEEE_SET_FP_CONTROL
> SYS$IEEE_SET_PRECISION_MODE
> SYS$IEEE_SET_ROUNDING_MODE
> 
> All documented and supported.

....which, of course, goes well beyond the highly touted "re-compile and re-link"
source-code compatibility (other than privileged code, that is).

-- 
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

In article <4661CE79.2F6A7B21@spam.comcast.net>, David J Dachtera
<djesys.no@spam.comcast.net> wrote:

>> For those of you keeping score at home, the three services are:
>> 
>> SYS$IEEE_SET_FP_CONTROL
>> SYS$IEEE_SET_PRECISION_MODE
>> SYS$IEEE_SET_ROUNDING_MODE
>> 
>> All documented and supported.
>
>...which, of course, goes well beyond the highly touted "re-compile and
re-link"
>source-code compatibility (other than privileged code, that is).

Who touted that, as an all-encompassing principle?  VMS Engineering has
always made it perfectly clear that some non-privileged code won't port
easily.

"Robert Deininger" <rdeininger@mindspringdot.com> wrote in message 
news:rdeininger-0306072027510001@dialup-4.233.152.234.dial1.manchester1.level3.net...
> In article <4661CE79.2F6A7B21@spam.comcast.net>, David J Dachtera
> <djesys.no@spam.comcast.net> wrote:
>
>>> For those of you keeping score at home, the three services are:
>>>
>>> SYS$IEEE_SET_FP_CONTROL
>>> SYS$IEEE_SET_PRECISION_MODE
>>> SYS$IEEE_SET_ROUNDING_MODE
>>>
>>> All documented and supported.
>>
>>...which, of course, goes well beyond the highly touted "re-compile and
> re-link"
>>source-code compatibility (other than privileged code, that is).
>
> Who touted that, as an all-encompassing principle?  VMS Engineering has
> always made it perfectly clear that some non-privileged code won't port
> easily.

The HW architecture-specific builtins are just that - HW specific.  In some 
cases, the usage was so widespread, and/or the replacement was so 
straightforward - that they were provided.

The apparent provenance of the __DIVx_C builtin was that they were provided 
for the people implementing the Alpha math library.  The belief/feeling was 
that they are only used by math & floating point experts who required 
something very specific, and that such experts would be aware that when the 
underlying floating point implementation completely changed - that they 
would need to use alternative methods.

Having said that, I believe (and have suggested internally) that we (HP/VMS) 
were remiss in not providing some type of writeup explaining the underlying 
usage and suggesting alternatives.

In the case of __DIVG_C - I don't think it would have been a good idea to 
try and emulate the instruction transparently.  It was provided to allow 
writing of some very specific high-performance math function - so wrapping a 
sys$ieee_set_rounding_mode call around it may have provided very poor 
performance if this builtin was inside a loop.

For the most part, typical C language programs are compile and go.  A 
typical C program doesn't use Alpha-specific builtins available only in HP 
C.

In article <f40vt1$i0a$1@usenet01.boi.hp.com>, "FredK" <fred.nospam@dec.com> writes:

> For the most part, typical C language programs are compile and go.  A 
> typical C program doesn't use Alpha-specific builtins available only in HP 
> C.

It seems to me the typical C program runs on Windows, MacOS or Linux.
People writing programs for VMS are likely doing something special,
and have no less reason to use special builtins than to use ASTs,
which they know are not portable to other operating systems.

The part that VMS programs hold in common with those other programs
is that the people porting them today are not the same individuals
who wrote them 15 years ago, and may have no domain expertise in the
particular type of coding involved.

After all, the only programs worth porting are those that have been
useful on Alpha, and those system-specific innards are the portions
least likely to have been changed for feature additions over the years.

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:3YYTG$PGoyh3@eisner.encompasserve.org...
> In article <f40vt1$i0a$1@usenet01.boi.hp.com>, "FredK" 
> <fred.nospam@dec.com> writes:
>
>> For the most part, typical C language programs are compile and go.  A
>> typical C program doesn't use Alpha-specific builtins available only in 
>> HP
>> C.
>
> It seems to me the typical C program runs on Windows, MacOS or Linux.
> People writing programs for VMS are likely doing something special,
> and have no less reason to use special builtins than to use ASTs,
> which they know are not portable to other operating systems.
>
> The part that VMS programs hold in common with those other programs
> is that the people porting them today are not the same individuals
> who wrote them 15 years ago, and may have no domain expertise in the
> particular type of coding involved.
>
> After all, the only programs worth porting are those that have been
> useful on Alpha, and those system-specific innards are the portions
> least likely to have been changed for feature additions over the years.

That is all well and good.  However, a instruction set difference which 
leads to a Alpha instruction set specific builtin feature to be missing is 
far different than ASTs.

Would you have been happier if the compiler silently inserted two calls and 
a divide and the program ended up 100 times slower - and of course the 
assumption would be that the CPU performance was horrible?

I agree that the documentation should have included information on 
strategies to replace the missing builtin function - including simply 
defining a macro that calls the IEEE function, does the divide and calls the 
IEEE function to restort the state.  I think however in this case - it 
really does call for someone to actually evaluate the code to determine the 
right course of action.

I have literally recompiled millions of lines of C code from Alpha.  It 
wasn't always pure compile and go - most of the changes were specific to 
architecture-specific #ifdef clauses.  But beyond that - it pretty much was 
a no-brainer.

David J Dachtera wrote:

> 
> 
> ...which, of course, goes well beyond the highly touted "re-compile and re-link"
> source-code compatibility (other than privileged code, that is).
> 

I'll freely admit that the differences in floating point between Alpha 
and Itanium may require some applications to change.  There is a white 
paper that we provided early on for the port to Itanium that tried to 
document all the issues.  Go to www.hp.com/go/openvms, click on 
Whitepapers, look for one titled "OpenVMS Floating Point whitepaper". 
It was published in 2003.  However, it was not updated to describe the 
various new system services and how/why/where to use them.  I agree with 
Fred that perhaps some additional documentation might be required. 
Where to put that?

Note that floating isn't the only place where you might have to change 
code.  Code that use the LIB$ calling standard routines (which have both 
hardware and calling standard implications) require some changes between 
Alpha and I64.

Re-compile, re-link, and re-test is a goal.  I think it happens most of 
the time.

-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

On Mon, 04 Jun 2007 05:17:36 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "Robert Deininger" <rdeininger@mindspringdot.com> wrote in message
> news:rdeininger-0306072027510001@dialup-4.233.152.234.dial1.manchester1.level3.net...
>> In article <4661CE79.2F6A7B21@spam.comcast.net>, David J Dachtera
>> <djesys.no@spam.comcast.net> wrote:
>>
>>>> For those of you keeping score at home, the three services are:
>>>>
>>>> SYS$IEEE_SET_FP_CONTROL
>>>> SYS$IEEE_SET_PRECISION_MODE
>>>> SYS$IEEE_SET_ROUNDING_MODE
>>>>
>>>> All documented and supported.
>>>
>>> ...which, of course, goes well beyond the highly touted "re-compile and
>> re-link"
>>> source-code compatibility (other than privileged code, that is).
>>
>> Who touted that, as an all-encompassing principle?  VMS Engineering has
>> always made it perfectly clear that some non-privileged code won't port
>> easily.
>
> The HW architecture-specific builtins are just that - HW specific.  In  
> some
> cases, the usage was so widespread, and/or the replacement was so
> straightforward - that they were provided.
>
> The apparent provenance of the __DIVx_C builtin was that they were  
> provided
> for the people implementing the Alpha math library.  The belief/feeling  
> was
> that they are only used by math & floating point experts who required
> something very specific, and that such experts would be aware that when  
> the
> underlying floating point implementation completely changed - that they
> would need to use alternative methods.
>
> Having said that, I believe (and have suggested internally) that we  
> (HP/VMS)
> were remiss in not providing some type of writeup explaining the  
> underlying
> usage and suggesting alternatives.
>
> In the case of __DIVG_C - I don't think it would have been a good idea to
> try and emulate the instruction transparently.  It was provided to allow
> writing of some very specific high-performance math function - so  
> wrapping a
> sys$ieee_set_rounding_mode call around it may have provided very poor
> performance if this builtin was inside a loop.
>
> For the most part, typical C language programs are compile and go.  A
> typical C program doesn't use Alpha-specific builtins available only in  
> HP
> C.
>
>
I respectfully disagree.  Requiring customers to recompile their apps is
bad enough and not providing transparency, because they are experts and
can fix it themselves is very poor business practice that borders on
arrogance.




-- 
PL/I for OpenVMS
www.kednos.com

"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.ttei9koltte90l@hyrrokkin...
> On Mon, 04 Jun 2007 05:17:36 -0700, FredK <fred.nospam@dec.com> wrote:
>>
>>
> I respectfully disagree.  Requiring customers to recompile their apps is
> bad enough and not providing transparency, because they are experts and
> can fix it themselves is very poor business practice that borders on
> arrogance.
>

I guess we will have to agree to disagree.  It simply isn't possible to make 
all things transparent.  Most of the changes that I have made to code was to 
"fix" architecture specific #ifdefs.  That is, conditional code for various 
architectures from VAX to Alpha to SPARC.  Sometimes the conditional really 
meant "if this isn't VAX - but was coded #ifdef ALPHA.  Sometimes it really 
meant "only on Alpha" and not on any other architecture".

To make that "transparent" would have meant to emulate *everything* that 
this implies and muddy things up bad like defining "__really_alpha" to 
differentiate between emulated Alpha in a compile and real Alpha hardware.

I have compiled *millions* of lines of code.  The *only* changes I have had 
to make in  unprivleged code was to fix #ifdef statements as appropriate.

If 1% of code (for example) needs to change, and the technical people say 
"in that 1% - someone really should look at the code - because anything we 
do might not be the right thing" - then it sounds to me to be a reasonable 
decision - not arrogance.

On Mon, 04 Jun 2007 08:55:17 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "Tom Linden" <tom@kednos-remove.com> wrote in message
> news:op.ttei9koltte90l@hyrrokkin...
>> On Mon, 04 Jun 2007 05:17:36 -0700, FredK <fred.nospam@dec.com> wrote:
>>>
>>>
>> I respectfully disagree.  Requiring customers to recompile their apps is
>> bad enough and not providing transparency, because they are experts and
>> can fix it themselves is very poor business practice that borders on
>> arrogance.
>>
>
> I guess we will have to agree to disagree.  It simply isn't possible to  
> make
> all things transparent.  Most of the changes that I have made to code  
> was to
> "fix" architecture specific #ifdefs.  That is, conditional code for  
> various
> architectures from VAX to Alpha to SPARC.  Sometimes the conditional  
> really
> meant "if this isn't VAX - but was coded #ifdef ALPHA.  Sometimes it  
> really
> meant "only on Alpha" and not on any other architecture".
>
> To make that "transparent" would have meant to emulate *everything* that
> this implies and muddy things up bad like defining "__really_alpha" to
> differentiate between emulated Alpha in a compile and real Alpha  
> hardware.
>
> I have compiled *millions* of lines of code.  The *only* changes I have  
> had
> to make in  unprivleged code was to fix #ifdef statements as appropriate.
>
> If 1% of code (for example) needs to change, and the technical people say
> "in that 1% - someone really should look at the code - because anything  
> we
> do might not be the right thing" - then it sounds to me to be a  
> reasonable
> decision - not arrogance.
>
>
Well, you have to say that the decision to proceed with the port to Itanium
after having recognized such problems was hardly a sound business  
decision, and
that, is where arrogance enters the equation.




-- 
PL/I for OpenVMS
www.kednos.com

"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tten3kn6tte90l@hyrrokkin...
> On Mon, 04 Jun 2007 08:55:17 -0700, FredK <fred.nospam@dec.com> wrote:
>
>>
> Well, you have to say that the decision to proceed with the port to 
> Itanium
> after having recognized such problems was hardly a sound business 
> decision, and
> that, is where arrogance enters the equation.
>

Yup.  Your logic wins.  We should have either made the VAX faster, or 
liquidated the company.

On Mon, 04 Jun 2007 12:17:40 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "Tom Linden" <tom@kednos-remove.com> wrote in message
> news:op.tten3kn6tte90l@hyrrokkin...
>> On Mon, 04 Jun 2007 08:55:17 -0700, FredK <fred.nospam@dec.com> wrote:
>>
>>>
>> Well, you have to say that the decision to proceed with the port to
>> Itanium
>> after having recognized such problems was hardly a sound business
>> decision, and
>> that, is where arrogance enters the equation.
>>
>
> Yup.  Your logic wins.  We should have either made the VAX faster, or
> liquidated the company.

I agree with your dialectics.  You would likely have gone into BK if
Compaq hadn't bought you.

I'll bet upgrading the VAX would have cost a fraction of the money
(WAG $10B) squandered on Alpha.  My experience with the PL/I test
suite, which is very extensive indeed, suggest to me that a VAX at
1/3 the clock of an Alpha will perform about the same.

Anyway, it's now history.  We have what we have.

-- 
PL/I for OpenVMS
www.kednos.com

In article <f4188t$p23$1@usenet01.boi.hp.com>, John Reagan <john.reagan@hp.com> writes:

> Note that floating isn't the only place where you might have to change 
> code.  Code that use the LIB$ calling standard routines (which have both 
> hardware and calling standard implications) require some changes between 
> Alpha and I64.

Yes, I hit that on the same program, but the answer was more obvious
(although I have still not finished addressing it).

FredK wrote:
> Would you have been happier if the compiler silently inserted two calls and 
> a divide and the program ended up 100 times slower - and of course the 
> assumption would be that the CPU performance was horrible?

Hasn't that been the case with programs that caused many alignment 
faults ? The programs compiled fine, but the execution performance was 
inferior to that on Alpha until someone would go into the code and 
rearrange things to reduce those faults ?

In fairness, *i* remember mention that there were floating point 
differences between Alpha and IA64 and that some programs would need to 
be changed. So it is not a surprise to see such occurances.

Tom Linden wrote:

> I respectfully disagree.  Requiring customers to recompile their apps is
> bad enough and not providing transparency, because they are experts and
> can fix it themselves is very poor business practice that borders on
> arrogance.

Because Alpha was a Digital product, they had the power to make it 
support VAX floating point formats to ease conversions.

However, since VAX floating point was developped, the IEEE standard has 
truly become de-facto and widely implemented standard. Alpha only 
delayed the inevitable need to wein applications from VAX floating point 
and go to IEEE.

On 06/04/07 14:17, Tom Linden wrote:
[snip]
> 
> I'll bet upgrading the VAX would have cost a fraction of the money
> (WAG $10B) squandered on Alpha.  My experience with the PL/I test
> suite, which is very extensive indeed, suggest to me that a VAX at
> 1/3 the clock of an Alpha will perform about the same.

The problem is that you can not ramp CISC designs beyond a couple of 
hundred MHz.  The circuits are just too complicated.

That's why for more than a decade, x86 CPUs have been RISC chips 
with "front-end" op-code decoders.

http://en.wikipedia.org/wiki/Micro-op

> Anyway, it's now history.  We have what we have.
> 


-- 
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On Mon, 04 Jun 2007 14:50:20 -0700, Ron Johnson <ron.l.johnson@cox.net>  
wrote:

> On 06/04/07 14:17, Tom Linden wrote:
> [snip]
>>  I'll bet upgrading the VAX would have cost a fraction of the money
>> (WAG $10B) squandered on Alpha.  My experience with the PL/I test
>> suite, which is very extensive indeed, suggest to me that a VAX at
>> 1/3 the clock of an Alpha will perform about the same.
>
> The problem is that you can not ramp CISC designs beyond a couple of  
> hundred MHz.  The circuits are just too complicated.

That simply isn't true.  I would hardly call X86 or 370 RISC, both of which
are CISC emulated on a simpler RISC-like core, much like the microcoded  
minis
of the 70's.
Moreover, cache and bandwidth requirements aren't as demanding for obvious
reasons.

I also don't buy Hennessy's analysis of the VAX.

>
> That's why for more than a decade, x86 CPUs have been RISC chips with  
> "front-end" op-code decoders.
>
> http://en.wikipedia.org/wiki/Micro-op
>
>> Anyway, it's now history.  We have what we have.
>>
>
>



-- 
PL/I for OpenVMS
www.kednos.com

Hi John,

> Note that floating isn't the only place where you might have to change
> code.  Code that use the LIB$ calling standard routines (which have both
> hardware and calling standard implications) require some changes between
> Alpha and I64.

Can you please provide a brief description of the changes reqd and the
profile of code that will require them? (or a pointer to specific docs)

As far as not wanting to SYS$IEEE_SET_FP_xxx for each subroutine (stack
unwinding issues, ASTs etc etc) can you please describe what was done to
control the user mode altering of big/little-endian in similar
circumstances?

Cheers Richard Maher

"John Reagan" <john.reagan@hp.com> wrote in message
news:f4188t$p23$1@usenet01.boi.hp.com...
> David J Dachtera wrote:
>
> >
> >
> > ...which, of course, goes well beyond the highly touted "re-compile and
re-link"
> > source-code compatibility (other than privileged code, that is).
> >
>
> I'll freely admit that the differences in floating point between Alpha
> and Itanium may require some applications to change.  There is a white
> paper that we provided early on for the port to Itanium that tried to
> document all the issues.  Go to www.hp.com/go/openvms, click on
> Whitepapers, look for one titled "OpenVMS Floating Point whitepaper".
> It was published in 2003.  However, it was not updated to describe the
> various new system services and how/why/where to use them.  I agree with
> Fred that perhaps some additional documentation might be required.
> Where to put that?
>
> Note that floating isn't the only place where you might have to change
> code.  Code that use the LIB$ calling standard routines (which have both
> hardware and calling standard implications) require some changes between
> Alpha and I64.
>
> Re-compile, re-link, and re-test is a goal.  I think it happens most of
> the time.
>
> -- 
> John Reagan
> OpenVMS Pascal/Macro-32/COBOL Project Leader
> Hewlett-Packard Company

Robert Deininger wrote:
> 
> In article <4661CE79.2F6A7B21@spam.comcast.net>, David J Dachtera
> <djesys.no@spam.comcast.net> wrote:
> 
> >> For those of you keeping score at home, the three services are:
> >>
> >> SYS$IEEE_SET_FP_CONTROL
> >> SYS$IEEE_SET_PRECISION_MODE
> >> SYS$IEEE_SET_ROUNDING_MODE
> >>
> >> All documented and supported.
> >
> >...which, of course, goes well beyond the highly touted "re-compile and
> re-link"
> >source-code compatibility (other than privileged code, that is).
> 
> Who touted that, as an all-encompassing principle?

Who said anything about "an all-encompassing principle"? I said, "highly
touted". Period - end of statement.

Read what I wrote - not what you think I wrote.

-- 
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

On 06/04/07 17:04, Tom Linden wrote:
> On Mon, 04 Jun 2007 14:50:20 -0700, Ron Johnson <ron.l.johnson@cox.net> 
> wrote:
> 
>> On 06/04/07 14:17, Tom Linden wrote:
>> [snip]
>>>  I'll bet upgrading the VAX would have cost a fraction of the money
>>> (WAG $10B) squandered on Alpha.  My experience with the PL/I test
>>> suite, which is very extensive indeed, suggest to me that a VAX at
>>> 1/3 the clock of an Alpha will perform about the same.
>>
>> The problem is that you can not ramp CISC designs beyond a couple of 
>> hundred MHz.  The circuits are just too complicated.
> 
> That simply isn't true.  I would hardly call X86 or 370 RISC, both of which
> are CISC emulated on a simpler RISC-like core, much like the microcoded 

You apparently did not read the Wikipedia article on Micro-op which 
I put into my post.  You really should.

Here's a 13 year old byte article

http://www.byte.com/art/9406/sec6/art2.htm

     From prefetch, instructions move into the decoder/scheduler,
     where for every cycle, one CISC instruction is translated into
     one or more RISC86 instructions. Unlike CISC instructions, the
     RISC86 instructions implement a load/store memory-access model.
     Also, they are fixed-length instructions, as opposed to
     variable-length CISC instructions. However, they are
     significantly longer than standard 32-bit RISC instructions.

Eventually, AMD bought NexGen and integrated RISC86 into all new x86 
products starting with the K6.  It's still in the x86-64 systems.

> minis
> of the 70's.
> Moreover, cache and bandwidth requirements aren't as demanding for obvious
> reasons.
> 
> I also don't buy Hennessy's analysis of the VAX.
> 
>>
>> That's why for more than a decade, x86 CPUs have been RISC chips with 
>> "front-end" op-code decoders.
>>
>> http://en.wikipedia.org/wiki/Micro-op
>>
>>> Anyway, it's now history.  We have what we have.
>>>
>>
>>
> 
> 
> 


-- 
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

JF Mezei wrote:
> FredK wrote:
> 
>> Would you have been happier if the compiler silently inserted two 
>> calls and a divide and the program ended up 100 times slower - and of 
>> course the assumption would be that the CPU performance was horrible?
> 
> 
> Hasn't that been the case with programs that caused many alignment 
> faults ? The programs compiled fine, but the execution performance was 
> inferior to that on Alpha until someone would go into the code and 
> rearrange things to reduce those faults ?
> 

I view alignment faults as something else.  Alignment faults are always 
cases where the user lied to the compiler.  When the compiler knows that 
something is unaligned (like an int inside some packed struct), we will 
generate multiple instructions to fetch/store the int in pieces.  Only 
when you fill in some pointer-to-int with a odd-byte address or pass 
some odd-byte address to an *int parameter do you get alignment faults. 
  It is just that on I64, such invalid programs incur a large 
performance hit.  Rearranging data is just one possible solution to fix 
the program.  Telling the compiler that the pointer points to unaligned 
data is another.

On the other hand, applications that want to mix various floating point 
settings are indeed legal.  However since the compilers cannot easily 
spot them, the solutions get compilicated without source code changes.


-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

Richard Maher wrote:

> 
> Can you please provide a brief description of the changes reqd and the
> profile of code that will require them? (or a pointer to specific docs)

The LIB$GET_INVO_CONTEXT routines (and friends) on Alpha take a pointer 
to a 32-bit context for the invo-context to be written into.  On I64, we 
needed a 64-bit context.  We couldn't keep the same name so we added 
LIB$I64_GET_INVO_CONTEXT (and friends).  They are all documented in the 
Calling Standard.  There is mostly a one-to-one mapping of the routines 
between Alpha and I64 so the vast majority of the cases I've seen just 
involve making the context variable grow from 32 to 64 bits and changing 
the names of the routines you call.  There are some new LIB$I64 routines 
added as well.

> 
> As far as not wanting to SYS$IEEE_SET_FP_xxx for each subroutine (stack
> unwinding issues, ASTs etc etc) can you please describe what was done to
> control the user mode altering of big/little-endian in similar
> circumstances?
> 

Well that is a little different.  The hardware lets you set the UM.BE 
bit at any time.  You probably won't get very far since all the address 
constants created by the linker are little-endian.  So you can't call 
out of the routine.  The operating system always clears UM.BE when it 
gets control so you can't set the bit in some exception handler or 
whatever and trick the OS (and mostly certainly crash it when it tripped 
over data that looked 'backwards').


-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message 
news:d4822$4664837c$cef8887a$31192@TEKSAVVY.COM...
> FredK wrote:
>> Would you have been happier if the compiler silently inserted two calls 
>> and a divide and the program ended up 100 times slower - and of course 
>> the assumption would be that the CPU performance was horrible?
>
> Hasn't that been the case with programs that caused many alignment faults 
> ? The programs compiled fine, but the execution performance was inferior 
> to that on Alpha until someone would go into the code and rearrange things 
> to reduce those faults ?
>

You pretty much need to do something explicit to cause misaligned data 
access.  It happens.  There is a performance penalty on every HW 
architecture.  The Alpha PAL code happened to fix up the fault "fairly" 
cheaply - but the code would have performed better if the alignment fault 
was fixed.      Because VMS is handling the fault and (for reasons I don't 
understand but am not an expert) has to take out a lock to fixup - it is 
very expensive on IA64.

The code works.  But slow.  We have lots of tools to track down alignment 
faults.  But no way to automatically fix the code - because the coder did 
something *explicit* to cause the problem and it isn't specific to an 
architecture.

On Tue, 05 Jun 2007 08:32:33 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
> news:d4822$4664837c$cef8887a$31192@TEKSAVVY.COM...
>> FredK wrote:
>>> Would you have been happier if the compiler silently inserted two calls
>>> and a divide and the program ended up 100 times slower - and of course
>>> the assumption would be that the CPU performance was horrible?
>>
>> Hasn't that been the case with programs that caused many alignment  
>> faults
>> ? The programs compiled fine, but the execution performance was inferior
>> to that on Alpha until someone would go into the code and rearrange  
>> things
>> to reduce those faults ?
>>
>
> You pretty much need to do something explicit to cause misaligned data
> access.  It happens.  There is a performance penalty on every HW
> architecture.  The Alpha PAL code happened to fix up the fault "fairly"
> cheaply - but the code would have performed better if the alignment fault
> was fixed.      Because VMS is handling the fault and (for reasons I  
> don't
> understand but am not an expert) has to take out a lock to fixup - it is
> very expensive on IA64.

Power uses a barrel shifter which incurs a one tick penalty.  The concept
has been around a long time, I first encountered ca. 1966.

>
> The code works.  But slow.  We have lots of tools to track down alignment
> faults.  But no way to automatically fix the code - because the coder did
> something *explicit* to cause the problem and it isn't specific to an
> architecture.
>
>
>
>



-- 
PL/I for OpenVMS
www.kednos.com

On Tue, 05 Jun 2007 01:42:49 -0700, Ron Johnson <ron.l.johnson@cox.net>  
wrote:

> On 06/04/07 17:04, Tom Linden wrote:
>> On Mon, 04 Jun 2007 14:50:20 -0700, Ron Johnson <ron.l.johnson@cox.net>  
>> wrote:
>>
>>> On 06/04/07 14:17, Tom Linden wrote:
>>> [snip]
>>>>  I'll bet upgrading the VAX would have cost a fraction of the money
>>>> (WAG $10B) squandered on Alpha.  My experience with the PL/I test
>>>> suite, which is very extensive indeed, suggest to me that a VAX at
>>>> 1/3 the clock of an Alpha will perform about the same.
>>>
>>> The problem is that you can not ramp CISC designs beyond a couple of  
>>> hundred MHz.  The circuits are just too complicated.
>>  That simply isn't true.  I would hardly call X86 or 370 RISC, both of  
>> which
>> are CISC emulated on a simpler RISC-like core, much like the microcoded
>
> You apparently did not read the Wikipedia article on Micro-op which I  
> put into my post.  You really should.
>
> Here's a 13 year old byte article

I read it 13 years ago!

Instructions sets are one thing and they way they are implemented in HW
is another.  There is absolutely no reason that a VAX couldn't be designed
today with the same clock speed as X86-64

Some instructions will certainly take multiple cycles to execute, but so  
what.
The RISC approach is to break it down into a simpler set of instructions.   
So
what might have been a single instruction on VAX of say 16 bytes, might be
18 instructions on a RISC, thus demaing larger memory bandwidth, caches and
pipelines.  Compare VAX and Alpha image sizes, for example.

>
> http://www.byte.com/art/9406/sec6/art2.htm
>
>      From prefetch, instructions move into the decoder/scheduler,
>      where for every cycle, one CISC instruction is translated into
>      one or more RISC86 instructions. Unlike CISC instructions, the
>      RISC86 instructions implement a load/store memory-access model.
>      Also, they are fixed-length instructions, as opposed to
>      variable-length CISC instructions. However, they are
>      significantly longer than standard 32-bit RISC instructions.
>
> Eventually, AMD bought NexGen and integrated RISC86 into all new x86  
> products starting with the K6.  It's still in the x86-64 systems.
>
>> minis
>> of the 70's.
>> Moreover, cache and bandwidth requirements aren't as demanding for  
>> obvious
>> reasons.
>>  I also don't buy Hennessy's analysis of the VAX.
>>
>>>
>>> That's why for more than a decade, x86 CPUs have been RISC chips with  
>>> "front-end" op-code decoders.
>>>
>>> http://en.wikipedia.org/wiki/Micro-op
>>>
>>>> Anyway, it's now history.  We have what we have.
>>>>
>>>
>>>
>>
>
>



-- 
PL/I for OpenVMS
www.kednos.com

"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.ttggejlktte90l@hyrrokkin...
> On Tue, 05 Jun 2007 08:32:33 -0700, FredK <fred.nospam@dec.com> wrote:
>

>
> Power uses a barrel shifter which incurs a one tick penalty.  The concept
> has been around a long time, I first encountered ca. 1966.
>

Remind me once again how we got here?  Trust me, fixing up an aligment fault 
isn't "just a barrel shifter".  It may be *one* of the things it does if all 
of the data is available in the cache.  Tell me how the barrel shifter works 
when it is a misaligned quadword fetch across a page boundry?

But in any case.  How did we somehow get from your rather pointed attack on 
business sense/ethics of migrating to hardware that wasn't 100% transparent 
at least at the compiler level - to tradeoffs in how to implement alignment 
faults in hardware?

I guess this is just a loop back to VAX compatibility.  Hey, I'd have loved 
it.  I'd have loved someone to prove the naysayers wrong.  The nVAX came 
pretty close as a starting point.  But nVAX was a day late and a dollar 
short.

The rest of your complaints about the Alpha instruction set...  When Alpha 
was being designed - the target was UNIX and VMS.  They made a calculated 
bet about the future of IO and the performance penalty of byte addressing. 
The bet about smart DMA devices is beginning to come true (RDMA etc) but has 
taken a lot longer than they envisioned.  When NT was added as a goal - the 
legacy of all the byte addressed device drivers ended up being an important 
problem to fix.  The actual code compactness and simplification for non-IO 
devices is second or third on the list of reasons to implement byte IO.

As to 16-bit math - I still don't understand the point on that one.

On 06/05/07 10:51, Tom Linden wrote:
> On Tue, 05 Jun 2007 01:42:49 -0700, Ron Johnson <ron.l.johnson@cox.net> 
> wrote:
> 
>> On 06/04/07 17:04, Tom Linden wrote:
>>> On Mon, 04 Jun 2007 14:50:20 -0700, Ron Johnson 
>>> <ron.l.johnson@cox.net> wrote:
>>>
>>>> On 06/04/07 14:17, Tom Linden wrote:
>>>> [snip]
>>>>>  I'll bet upgrading the VAX would have cost a fraction of the money
>>>>> (WAG $10B) squandered on Alpha.  My experience with the PL/I test
>>>>> suite, which is very extensive indeed, suggest to me that a VAX at
>>>>> 1/3 the clock of an Alpha will perform about the same.
>>>>
>>>> The problem is that you can not ramp CISC designs beyond a couple of 
>>>> hundred MHz.  The circuits are just too complicated.
>>>  That simply isn't true.  I would hardly call X86 or 370 RISC, both 
>>> of which
>>> are CISC emulated on a simpler RISC-like core, much like the microcoded
>>
>> You apparently did not read the Wikipedia article on Micro-op which I 
>> put into my post.  You really should.
>>
>> Here's a 13 year old byte article
> 
> I read it 13 years ago!
> 
> Instructions sets are one thing and they way they are implemented in HW
> is another.  There is absolutely no reason that a VAX couldn't be designed
> today with the same clock speed as X86-64

If the x86 ISA can be micro-architectured, so can the VAX 
instruction set.  That would take a lot of work, though.

But then, maybe not.  IBM lets just about anyone take PPC cores and 
add whatever they want, to make a functional chip.  Add cache and 
VAX op-code decoding logic and /hey presto/ you've got a modern VAX.

> Some instructions will certainly take multiple cycles to execute, but so 
> what.
> The RISC approach is to break it down into a simpler set of 
> instructions.  So
> what might have been a single instruction on VAX of say 16 bytes, might be
> 18 instructions on a RISC, thus demaing larger memory bandwidth, caches and
> pipelines.  Compare VAX and Alpha image sizes, for example.

-- 
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

John Reagan wrote:
(snip)

> I view alignment faults as something else.  Alignment faults are always 
> cases where the user lied to the compiler.  When the compiler knows that 
> something is unaligned (like an int inside some packed struct), we will 
> generate multiple instructions to fetch/store the int in pieces.  Only 
> when you fill in some pointer-to-int with a odd-byte address or pass 
> some odd-byte address to an *int parameter do you get alignment faults. 
>  It is just that on I64, such invalid programs incur a large performance 
> hit.  Rearranging data is just one possible solution to fix the 
> program.  Telling the compiler that the pointer points to unaligned data 
> is another.

In the Fortran 66 days COMMON blocks were required to be packed.
It might be that isn't true anymore, but it did cause problems.

The compiler could know at compile time directly referencing a COMMON
variable, but not if it was passed as a subroutine argument.

Some systems I used would trap the addressing exception, copy the
data, perform the operation on the copy, and copy back.  That is
much slower than even your multiple instruction form.

-- glen

(snip)
>> On 06/04/07 17:04, Tom Linden wrote:
(snip)

>>>  That simply isn't true.  I would hardly call X86 or 370 RISC, 
>>> both of  which are CISC emulated on a simpler RISC-like core,
 >>> much like the microcoded

370 has some RISC characteristics and some very CISC characteristics.

Mostly two addressing modes and three different instruction lengths,
and the actual instructions generated by most compilers are the
simpler ones.  There are some fairly complicated instructions,
such as EDIT, meant for microcode or, in newer systems, millicode.

I remember stories from the early VAX days that, for example, POLY
was slower than evaluating a polynomial in multiple add/multiply
instructions.  I don't know if that changed in later years.

-- glen

glen herrmannsfeldt wrote:

> The compiler could know at compile time directly referencing a COMMON
> variable, but not if it was passed as a subroutine argument.
> 

Then any reasonable compiler would just have to assume that subroutine 
arguments are only byte aligned if you are packing your COMMON blocks.


-- 
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

On Tue, 05 Jun 2007 11:11:03 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "Tom Linden" <tom@kednos-remove.com> wrote in message
> news:op.ttggejlktte90l@hyrrokkin...
>> On Tue, 05 Jun 2007 08:32:33 -0700, FredK <fred.nospam@dec.com> wrote=
:
>>
>
>>
>> Power uses a barrel shifter which incurs a one tick penalty.  The  =

>> concept
>> has been around a long time, I first encountered ca. 1966.
>>
>
> Remind me once again how we got here?  Trust me, fixing up an aligment=
  =

> fault
> isn't "just a barrel shifter".  It may be *one* of the things it does =
if  =

> all
> of the data is available in the cache.  Tell me how the barrel shifter=
  =

> works
> when it is a misaligned quadword fetch across a page boundry?

Look, if IBM can do it, so can you.  These type of technical problems ar=
e
eminently solvable as they have demonstrated.

>
> But in any case.  How did we somehow get from your rather pointed atta=
ck  =

> on
> business sense/ethics of migrating to hardware that wasn't 100%  =

> transparent
> at least at the compiler level - to tradeoffs in how to implement  =

> alignment
> faults in hardware?

I only discussed the business aspect, ethics has nothing to do with it.
We could, I supposed, debate what might have been, all I am saying is th=
at
introducing new incompatible architecture as Digital/Compaq/HP have done=

is stupid from a business point of view, for a whole variety of reasons.=


IBM has not done that since the 360 was introduced.  But wait a minute, =
the
360 gave way to the 370, addressing went fro 24 bits to XA (31 bits) and=
  =

then
64 Unix features were added to z/os, and you can still run OS360 Object =
 =

modules.

They (IBM)got it right and are reaping the benefits, Digital has been  =

teetering on
extinction from these notoriously bad decisions.

Alpha was a mistake.  Itanium is a mistake

>
> I guess this is just a loop back to VAX compatibility.  Hey, I'd have =
 =

> loved
> it.  I'd have loved someone to prove the naysayers wrong.  The nVAX ca=
me
> pretty close as a starting point.  But nVAX was a day late and a dolla=
r
> short.
>
> The rest of your complaints about the Alpha instruction set...  When  =

> Alpha
> was being designed - the target was UNIX and VMS.  They made a calcula=
ted
> bet about the future of IO and the performance penalty of byte  =

> addressing.
> The bet about smart DMA devices is beginning to come true (RDMA etc) b=
ut  =

> has
> taken a lot longer than they envisioned.  When NT was added as a goal =
-  =

> the
> legacy of all the byte addressed device drivers ended up being an  =

> important
> problem to fix.  The actual code compactness and simplification for  =

> non-IO
> devices is second or third on the list of reasons to implement byte IO=
..
>
> As to 16-bit math - I still don't understand the point on that one.
>
21064 cpu's could do the arithmetic very well.  c =3D a + b tooks 17 tic=
s
for 16 bit and 4 tics for 32 bit integers, IIRC.  Ignoring the customer
base requirements when designing a new chip, is frankly stupid.



-- =

PL/I for OpenVMS
www.kednos.com

Tom Linden wrote:

> Look, if IBM can do it, so can you.  These type of technical problems are
> eminently solvable as they have demonstrated.


Hindsight is 20/20.

Remember how Digital had presentations showing how IA64 was a flawed 
architecture that could never catch up to alpha ? What if the Alpha guys 
had similar presentations telling Ken Olsen that VAX had no future ?

The VAX guys were still working on real 32 bit VAXes, instead of trying 
to "RISCify the vax implementation by having a risc engine behind a VAX 
instruction decoder and perhaps making it 64 bits. Had they done the 
later, they may have been able to tell Olsen that they would not hit a 
brick wall and performance would have continued to increase for a very 
long time.

But if the VAX guys were unable to convince Olsen that the Alpha 
anti-vax arguments were not correct, then Olsen would have been correct 
in making the decision to go with Alpha if VAX was seen reaching a dead end.

Intel was able to plow through the brick wall with its 8086 because of 
the amounts of resources it could afford to put on that product line, as 
  well as the alpha secrets it started using with pentium 3.

But intel's breakthrough with 8086 happened after Alpha came into 
existance. Before that, the 8086 architeture was also seen as a dead 
end, about to hit a brick wall. (And that was one of the reasons Intel 
started to toy around with a replacement architecture that became that 
IA64 dead weight.)


Yes, in hindsight, it would have been possible to turn the vax into a 64 
bit superfast chip.  But at the time the decision was made, there wasn't 
that knowledge.

On Wed, 06 Jun 2007 17:25:56 -0700, JF Mezei  
<jfmezei.spamnot@vaxination.ca> wrote:

> Tom Linden wrote:
>
>> Look, if IBM can do it, so can you.  These type of technical problems  
>> are
>> eminently solvable as they have demonstrated.
>
>
> Hindsight is 20/20.
>
> Remember how Digital had presentations showing how IA64 was a flawed  
> architecture that could never catch up to alpha ? What if the Alpha guys  
> had similar presentations telling Ken Olsen that VAX had no future ?
>
> The VAX guys were still working on real 32 bit VAXes, instead of trying  
> to "RISCify the vax implementation by having a risc engine behind a VAX  
> instruction decoder and perhaps making it 64 bits. Had they done the  
> later, they may have been able to tell Olsen that they would not hit a  
> brick wall and performance would have continued to increase for a very  
> long time.
>
> But if the VAX guys were unable to convince Olsen that the Alpha  
> anti-vax arguments were not correct, then Olsen would have been correct  
> in making the decision to go with Alpha if VAX was seen reaching a dead  
> end.
>
> Intel was able to plow through the brick wall with its 8086 because of  
> the amounts of resources it could afford to put on that product line, as  
>   well as the alpha secrets it started using with pentium 3.
>
> But intel's breakthrough with 8086 happened after Alpha came into  
> existance. Before that, the 8086 architeture was also seen as a dead  
> end, about to hit a brick wall. (And that was one of the reasons Intel  
> started to toy around with a replacement architecture that became that  
> IA64 dead weight.)
>
>
> Yes, in hindsight, it would have been possible to turn the vax into a 64  
> bit superfast chip.  But at the time the decision was made, there wasn't  
> that knowledge.
Yes it was.


-- 
PL/I for OpenVMS
www.kednos.com

"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.ttiwysk4tte90l@hyrrokkin...
On Tue, 05 Jun 2007 11:11:03 -0700, FredK <fred.nospam@dec.com> wrote:


Tom,

I am sorry that you are upset, or that I somehow responded in a way to send 
you down this path.  It wasn't my intent.  I'll restrict my posts to 
technical issues where I happen to have the answer.

John Reagan wrote:

> glen herrmannsfeldt wrote:

>> The compiler could know at compile time directly referencing a COMMON
>> variable, but not if it was passed as a subroutine argument.

> Then any reasonable compiler would just have to assume that subroutine 
> arguments are only byte aligned if you are packing your COMMON blocks.

Well, it should happen relatively rarely, and the overhead for doing
that is too high on many machines.  For S/360 it would require a few
extra instructions for each memory access.  S/370 removed the alignment
requirement, though it is usually significantly slower.

Many RISC processors require data to be aligned, though.

-- glen

On Thu, 07 Jun 2007 13:58:27 -0700, FredK <fred.nospam@dec.com> wrote:

>
> "Tom Linden" <tom@kednos-remove.com> wrote in message
> news:op.ttiwysk4tte90l@hyrrokkin...
> On Tue, 05 Jun 2007 11:11:03 -0700, FredK <fred.nospam@dec.com> wrote:
>
>
> Tom,
>
> I am sorry that you are upset, or that I somehow responded in a way to  
> send
> you down this path.  It wasn't my intent.  I'll restrict my posts to
> technical issues where I happen to have the answer.
>
>
Fred, I am not upset.  I just am disappointed and saddened by the ongoing
mismanagement of VMS for at least the last 20 years.  I ask KO for license
to port it ca. 1982, and the only supporter was Andy Knowles.  Not that I  
could
have made a significant difference, but had the epiphany materlized at  
Digital,
it might have been a different world today.  You would be writing PL/I:-)



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/