|
I would like to amend and extend the proposal a bit (hey, if they
can amend the constitution...)
Bob
With respect to the variant record case, I would like to revisit this
issue. Upon further consideration, I don't believe the btStruct_64
suggested modification is a good approach.
Consider the following Pascal program fragment and its corresponding symbol
table, which contains a variant record:
type
rec1 = record
case integer of
1,3,5,7,9 : (f1 : integer);
otherwise (f2 : real);
end;
Binary of auxes:
0. 0x00000000 0x00000018 0x00000015 0x00000000 0x00000030
5. 0x00002fff 0x00000001 0x00000005 0x00001fff 0x00000001
10. 0x00000009 0x00000009 0x00001fff 0x00000001 0x00000007
15. 0x00000007 0x00001fff 0x00000001 0x00000005 0x00000005
20. 0x00001fff 0x00000001 0x00000003 0x00000003 0x00001fff
25. 0x00000001 0x00000001 0x00000001 0x00000028 0x00000001
30. 0x00001fff 0x00000001 0x80000000 0x7fffffff 0x00000013
35. 0x00000000
Local Symbols:
from file other.pas Printf aux if present
0. ( 0)( 0) other.pas File Text symref 22
1. ( 1)(0x1200017a8) DBGRECV StaticProc Text [ 2] endref 21, btNil
2. ( 2)( 0x4) REC1 Block Info symref 13
3. ( 3)( 0) Member Info [ 1] int
4. ( 3)( 0x3) Block Variant symref 12
5. ( 4)( 0x7) Block Info symref 8
6. ( 5)( 0) F1 Member Info [ 1] int
7. ( 4)( 0) End Info symref 5
8. ( 4)(0x1d) Block Info symref 11
9. ( 5)( 0) F2 Member Info [28] float
10. ( 4)( 0) End Info symref 8
11. ( 3)( 0x3) End Variant symref 4
12. ( 2)( 0) REC1 End Info symref 2
13. ( 2)(0x18) Block Text symref 20
14. ( 3)(0xfffffffffffffff0) VREC Local Abs [ 4] struct(exten
ded file 1, index 2)
15. ( 3)(0x1200017a0) B StaticProc Text [34] endref 19, btNil
16. ( 4)( 0x4) Block Text symref 18
17. ( 4)( 0x4) End Text symref 16
18. ( 3)( 0x8) B End Text symref 15
19. ( 2)(0x2c) End Text symref 13
20. ( 1)(0x3c) DBGRECV End Text symref 1
21. ( 0)( 0) other.pas End Text symref 0
The aux sequence for the variant record component of the begins at
aux record 7:
5. [*0x00000005 0x00001fff 0x00000001
10. 0x00000009 0x00000009 0x00001fff 0x00000001 0x00000007
15. 0x00000007 0x00001fff 0x00000001 0x00000005 0x00000005
20. 0x00001fff 0x00000001 0x00000003 0x00000003 0x00001fff
25. 0x00000001 0x00000001 0x00000001*]
Here is the description of how to interpret the auxes.
!
! The value field for each block within a variant block
! will point to the aux being created here, which will
! consist of:
!
! 1 - a count of the range of values for this variant
! (usually 1)
! 2 - for each range of values, a RNDX record for the selector
! 3 - the low value for the range
! 4 - the high value for the range
!
With the current approach, the btStruct which precedes this sequence
would be modified to bt_Struct64 if any of the range values require
64 bits. If any one such value would require 64 bits, then all such
range values would need to be 64 bits as well.
I believe that the modifying the btStruct is not a good approach for
this case. For variant records, btStruct is a "high level" description
in the aux sequence for the record. It would be better to convey the
64 "bitness" of the record at a lower level, limiting its application
to what is needed for, i.e. the ranges.
If you consider the nesting allowed with structures/variant records,
it makes sense to represent the 64 bit modification in a less global
manner, to avoid unnecessary complexity.
Here is a proposal for modifying the representation of record variants.
The represenation begins with a count of the number of ranges. Immediately
following the count, I propose that a btRange or btRange_64 basic type
aux record be inserted into the stream, depending upon the size
requirements of the variant record bounds. Note that the sequence
that would follow the btRange/btRange_64 type is identical to the
sequence currently used with btRange to implement range types (note
the exception of replication, which is not implemented with btRange
for range types).
Since the description of a range and the selection criteria for a
a variant are conceptually identical, this approach is a logical one.
Another current limitation with variant records is the lack of ability
to represent the "otherwise" or default case of selection of the variant
(i.e. the case to choose when all other cases fail).
I propose that we represent that case with the current model and
substitute the smallest (negative) and largest 32 or 64 bit number,
(32 or 64 bit based up whether btRange or btRange64 is specified,
respectively) for the low and high bounds of the range (respectively).
If there were more than a single range, then this case would be
understood to be interpreted as the "otherwise" case. If it were
the only case, then it would be interpreted as is (I realize that
this is not perfect, but given the constraints of the symbol
table, seems good enough).
|
| <Sounds of PeterT whopping Monteleone over the head with a heavy
keyboard>
Oh, fine. After I put btStruct_64 into symconst.h, you're now telling
me we don't need it. Sigh....
Well, I must admit, making all the changes for this, I couldn't quite
see how btStruct_64 was going to be used or be of any use...
Looks semi-reasonable on a quick first glance. Will get back to you...
PeterT
|
| Bob,
I'm pleased you decided to reconsider the variant record representation.
The 64-bit indication did seem too "far away" from the range bounds.
One thing: Is there anyplace else to hide the count? Could we use the
width mechanism in the TIR, if it won't be needed for anything else? It's
an overloading, but the variant representation is already so... pardon my
French... Although I guess Pascal uses the width more than other languages.
It just might be nice if we could follow the "first aux is a TIR" general
rule. And I assume you have in mind one TIR for the whole thing (all
ranges interpreted as 32 bits or all as 64 bits)?
-Michelle
[Posted by WWW Notes gateway]
|