| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2667.1 | | TLE::REAGAN | All of this chaos makes perfect sense | Fri Apr 04 1997 17:34 | 23 |
| .PEN files are not .OBJ files. You cannot use ANAL/OBJ to read/format
them. They are a totally private binary file that is read/written only
by the compiler itself (they are essentially compressed symbol tables).
As for why? Because we say so, thats why.
Honestly, the reason is because it would have been more work to allow
it.
Consider moving a PEN file from an Alpha to a VAX that contained IEEE
floating point types. Or moving a PEN file from VAX to Alpha that
contained an H_Floating floating type.
The part of the compiler that reads PEN files makes the assumption that
everything in the PEN file is OK on the platform. We would have to add
some code to check the PEN file as it was being inherited for things
that wouldn't work on that platform. Another example is moving a PEN
file to/from Digital UNIX (where addresses are 64 bits) to OpenVMS
Alpha/VAX (where addresses are only 32 bits). Again, the compiler
would be caught off guard then it inherited something from the PEN file
that it couldn't have ever seen directly.
-John
|
| 2667.2 | | AUSS::GARSON | DECcharity Program Office | Sun Apr 06 1997 23:00 | 16 |
| re .0
Presumably also a platform specific format allows the internal
structure to be made more efficient for processing on the target
platform e.g. less "packed" structures on Alpha. Similarly, if Digital
wanted to make improvements in the format, based on experience of many
years of VAX, we would not want to be tied down to *ward compatibility
for an internal format where this was never promised.
Some compilations that produce .PEN files *must* also produce .OBJ files
- and it isn't always obvious. In that situation, the compilation would
have to be done twice, once for each platform, even if one could get away
with throwing away one .PEN file.
The customer hasn't clearly stated what *benefit* would be derived for
the customer from a common .PEN format.
|
| 2667.3 | | TLE::REAGAN | All of this chaos makes perfect sense | Mon Apr 07 1997 13:34 | 29 |
| RE: .2
Yes, we did consider the "packing" of the fields in the PEN file when
moving DEC Pascal to Alpha. Fortunately, we had years of luck and the
vast majority of the PEN file's layout was already naturally aligned.
We decided not to make the PEN files differnent due to the 2 or 3
fields that we're not aligned (especially since you read them only once
from the file and we made the "in-memory" version aligned properly).
As for "improvements", we have made changes to the PEN file format
over the years to fix bugs or add new features. At those times, we
added code to the "inherit" code that dealt with older PEN file
formats. And since the "inherit" code is "common" code (the code
is aware somewhat of address-size, etc. but those platform-specific
values are coded as macros/symbolic-constants), adding code to support
new formats falls out for all the platforms. Even if we wanted to make
drastic changes just for the Alpha platform, the fact that we have to
understand current PEN files means we'll carry around that code
forever.
The observation that one might have to compile on each platform anyway
to get the corresponding .OBJ file is one that I overlooked (thanks!).
So, yes, in theory the physical layout of the PEN files is understood
by all the other compilers. It is the rest of the compiler that would
get confused by finding symbol tables for things it didn't think was
possible on that platform.
-John
|
| 2667.4 | | AUSS::GARSON | DECcharity Program Office | Mon Apr 07 1997 22:53 | 17 |
| re .3
> Yes, we did consider the "packing" of the fields in the PEN file when
> As for "improvements", we have made changes to the PEN file format
I was "fishing" somewhat for possible reasons not to support VAX .PEN
files on Alpha.
Even so, your answer regarding improvements over time to the VAX .PEN
file format suggests that you are making a (small?) trade-off in favour
of ease of maintenance of the code base over carrying code into the
Alpha compiler than can never execute? In theory Alpha gives you the
chance not to support ancient, odd variants of PEN files in the name of
*ward compatibility. The decision that the Alpha compiler does not
support VAX PEN files still allows you flexibility in the future to have
somewhat different code bases for "inherit"?
|
| 2667.5 | | TLE::REAGAN | All of this chaos makes perfect sense | Tue Apr 08 1997 13:34 | 10 |
| Correct. We have the option of future Alpha changes since we don't
support inheriting PEN files from 1982. I don't know if we'll ever
use the opertunity, but it is there.
We did consider adding some conditional %IF/%FI conditionals so the
"old VAX PEN file" dead code wouldn't even appear in the Alpha
compiler, but its probably only a couple of hundred bytes of code.
So, yes, we carry around code that can't execute.
-John
|