Re:
> In 6.5 the addition of "Large Files"(>4GB) to the FOS shows clearly how
> committed HP is to the MPE - that is to say: "They are not". It(Large
> Files implementation) is a joke.
I'd have to disagree. I think that the lab made a major effort, and
implemented a significant new feature in a pretty short timeframe.
> It is so incomplete in its implementation as to be laughable.
I'm lost here...it's probably more complete than, say, 64-bit files on
Unix systems.
It's not done, of course. We still need to see all file types (including
byte stream) implement > 4 GB.
Keep in mind that MPE has *much* more work than a simple-minded operating
system like Unix. With Unix, all one has are "byte stream" files.
There is *NO* structured file type. MPE has a lot: byte stream,
fixed record, variable record, message files, KSAM/iX, RIO, and Circular
files. (Ok, and directory files)
CSY knew they didn't have the resources to make all of those types of files
Large Files in the same release, so they chose the most frequently used
ones for the first release ... and I think that's appropriate.
> It produces inconsistent results, depending on the machine you use,
Like on Unix? :)
Like on MPE V vs. MPE XL vs. MPE/iX (when we went from 2 GB to 4 GB files)?
I guess I'm saying: there are two kinds of inconsistent results:
1) running on an older system (that doesn't support Large Files)
and requesting a Large File (that's the Unix and MPE V/XL/iX comparison)
...those are to be expected, and the 6.5 vs. 6.0 ones are the same
as the MPE/iX (with 4 GB max) to MPE XL (with 2 GB max) ones.
2) any other kind you might mean.
I'd be interested in knowing what you meant.
> It produces inconsistent results, depending on [...] what the current load is
huh?
>, etc, etc. The languages were
> not changed to allow you to do 64 bit pointer manipulation.
I'm aware of only three languages that support 64-bit pointers:
Pascal/iX, C/iX, and SPLash!
...and, you're right: none of them directly support 64-bit pointer
manipulation. (Their manipulations are limited to the bottom 32-bits of
the 64-bit address...which works for long mapped files, but not Large Files.)
But...HP provided intrinsics to do such access:
HPFADDTOPOINTER ... does proper 64-bit arithmetic for pointer add/subtract
HPFMOVEDATA ... properly moves data to/from a Large File
HPFMOVEDATALTOR ... ditto, in a known order (allowing "clever"
data overlap tricks)
HPFMOVEDATARTOL ... ditto, in a known order (allowing "clever"
data overlap tricks)
The other facilities that Unix lacks and sorely needs, like post()
and prefetch(), also support Large Files.
OTOH, MPE has had a history of what seems like at least 10 years of
neglect from the Compiler Language group within HP. ... but that's not
new ... we've been complaining about it for years!
> The only
> facility added to do so, is a single intrinsic call, to add a constant
> to a pointer.
4 intrinsics
> than just adding a constant. How absolutely irresponsible. Now the only
> way to add one to your 64 bit pointer is to call an intrinsic. Intrinsic
> calls are not cheap. They incur a great deal of overhead. The calls to
On a 927, HPFADDTOPOINTER takes about 24 microseconds.
If you "roll your own" HPFADDTOPOINTER, it takes about 2 microseconds
(unoptimized, and 0.8 microseconds if compiled with the optimizer on).
So, if you had a file with 100 million 80 byte records (8 GB), and did
one HPFADDTOPOINTER call per record, that's about 2400 seconds of
time ... but ...let's say you spent 0.5 seconds of CPU processing
each record (not counting the HPFADDTOPOINTER call)... that's
about 18 months of CPU time, out of which 2400 seconds is pretty small.
> The calls to
> get a 64 bit file pointer to a LARGE file that is already opened, cannot
> be used, even though they are added with 6.5 and documented, even though
> they appear to work, almost all the time, and on some machines, 100% of the
> time.
Huh?
> The documentation for the new intrinsics they provided are truly at
> the most fundamental level, incorrect(Parameters are not the types
> described), and incomplete.
I noticed one small difference between the *preliminary* documentation
I received, and the actual final documentation.
BTW, CSEQ shows:
CSEQ [2.9] - LPS Toolbox [A.07a] (c) 1995 Lund Performance Solutions
Procedure HPFADDTOPOINTER (
base_ptr : anyvar record ; {R25, R26}
{Address type = LongAddr}
offset : anyvar record ; {R23, R24}
{Address type = LongAddr}
return_ptr : anyvar record ; {SP-$0038,8}
{Address type = LongAddr}
status : anyvar int32 ) {SP-$003c} := nil
{adds 64 bit offset to base_ptr, returns }
{resulting 64-bit pointer in return_ptr. }
{Note: offset can be negative. }
{status: overall result (0 = ok) }
uncheckable_anyvar
Procedure HPFMOVEDATA (
count : anyvar record ; {R25, R26}
{Address type = LongAddr}
source_ptr : anyvar record ; {R23, R24}
{Address type = LongAddr}
target_ptr : anyvar record ; {SP-$0038,8}
{Address type = LongAddr}
status : anyvar int32 ) {SP-$003c} := nil
{moves count bytes from source_ptr to target_ptr. }
{Note: supports Large Mapped Files. }
{status: overall result (0 = ok) }
{NOTE: source/target should not overlap! }
uncheckable_anyvar
Procedure HPFMOVEDATALTOR (
count : anyvar record ; {R25, R26}
{Address type = LongAddr}
source_ptr : anyvar record ; {R23, R24}
{Address type = LongAddr}
target_ptr : anyvar record ; {SP-$0038,8}
{Address type = LongAddr}
status : anyvar int32 ) {SP-$003c} := nil
{moves count bytes from source_ptr to target_ptr. }
{Note: supports Large Mapped Files. }
{status: overall result (0 = ok) }
{NOTE: starts at left end of source/target. }
uncheckable_anyvar
Procedure HPFMOVEDATARTOL (
count : anyvar record ; {R25, R26}
{Address type = LongAddr}
source_ptr : anyvar record ; {R23, R24}
{Address type = LongAddr}
target_ptr : anyvar record ; {SP-$0038,8}
{Address type = LongAddr}
status : anyvar int32 ) {SP-$003c} := nil
{moves count bytes from source_ptr to target_ptr. }
{Note: supports Large Mapped Files. }
{status: overall result (0 = ok) }
{NOTE: starts at right end of source/target. }
uncheckable_anyvar
> and their refusal to do so is further evidence. That management allowed a
> design and implementation that consistently, knowingly, produces
> inconsistent
> results, would in some cultures result in such "loss of face" as to have the
> problem be "self remediating".
I'd be interested in knowing more about this. Are there bugs in
Large Files? (I know of one, which has a patch, which affected the
reporting of the EOF in some cases.)
> year plan is meaningful, I have lived through this before. The HP260 was
> another machine that HP wanted to get rid of. They had a 5 and 10 year
> plan, including hardware and software, that the head of development told
> the HP260 community, as well as to the company I worked for specifically,
> in person. Then two months later, HP pulled the plug, and left us all high
> and dry.
I think that's a cautionary tale that we should all keep in mind.
No matter how dedicated Winston and CSY is, they are at the mercy of
higher-level managers who have frequently killed golden geese for a quick
bite of pate.
Stan Sieler [log in to unmask]
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
|
