representation of types 
Author Message
 representation of types

Can anyone tell me how Oberon RECORDs are typically represented?  I
thought the tag that gives the run-time type information would be like
the hidden pointer in C++ classes--stored with the record.  This would
certainly provide a dynamic method for accessing type-bound procedures,
and would only be expensive if a lot of instances of a small record were
allocated, but would make memory-mapped i/o more difficult (for example:
using a record for the character/attribute pairs in the PCs screen memory
would depend on a packed record with no extra baggage).

Experimenting with the SIZE procedure in Extacy.EXE yields results that
don't reflect any extra expense for a tag field.

Thanks much,

Brent Rowland



Sun, 19 May 1996 12:14:05 GMT  
 representation of types

Quote:

> Can anyone tell me how Oberon RECORDs are typically represented?  I
> thought the tag that gives the run-time type information would be like
> the hidden pointer in C++ classes--stored with the record.  This would
> certainly provide a dynamic method for accessing type-bound procedures,
> and would only be expensive if a lot of instances of a small record were
> allocated, but would make memory-mapped i/o more difficult (for example:
> using a record for the character/attribute pairs in the PCs screen memory
> would depend on a packed record with no extra baggage).

Depends on your compiler. For example Amiga-Oberon puts the type tag
as first element into every record (this has advantages in interfacing
Amiga-OS).

Other compilers would use a type tag for runtime-allocated
RECORDs only, putting it before the RECORD itself, but omit it from static
variables since their type is know at compiletime.
--



Mon, 20 May 1996 21:05:27 GMT  
 representation of types

Quote:

>Can anyone tell me how Oberon RECORDs are typically represented?  I
>thought the tag that gives the run-time type information would be like
>the hidden pointer in C++ classes--stored with the record.  This would
>certainly provide a dynamic method for accessing type-bound procedures,

This is, indeed, how it is generally done -- a hidden pointer
preceding the dynamically allocated recoed.

Quote:
>and would only be expensive if a lot of instances of a small record were
>allocated, but would make memory-mapped i/o more difficult (for example:
>using a record for the character/attribute pairs in the PCs screen memory
>would depend on a packed record with no extra baggage).

The procedures SYSTEM.GET and SYSTEM.PUT are Wirth's answer
for this kind of direct memory access.  An alternative would
be to have a way of placing a record variable at a specific
address.  Because it's statically allocated, there would be no
hidden type tag to "get in the way".  I've seen some Modula-2
systems with this feature.

--
And in the heartbreak years that lie ahead,
Be true to yourself and the Grateful Dead.
                                -- Joan Baez



Mon, 20 May 1996 22:23:35 GMT  
 representation of types

Quote:
>Can anyone tell me how Oberon RECORDs are typically represented?  I
>thought the tag that gives the run-time type information would be like
>the hidden pointer in C++ classes--stored with the record.  This would
>certainly provide a dynamic method for accessing type-bound procedures,
>and would only be expensive if a lot of instances of a small record were
>allocated, but would make memory-mapped i/o more difficult (for example:
>using a record for the character/attribute pairs in the PCs screen memory
>would depend on a packed record with no extra baggage).
>Experimenting with the SIZE procedure in Extacy.EXE yields results that
>don't reflect any extra expense for a tag field.

Extacy.EXE uses the same type representation as the original Oberon
system:
        a hidden type tag is added for dynamically allocated
        records only.

For variables of record type its type is knows statically
and for record VAR parameter an additional hidden parameter is
passed.

Example:
TYPE
  P = POINTER TO R;
  R = RECORD
        ...fields..
        PROCEDURE (p: P) Method;
      END

VAR p: P;
                          hidden type tag -----> type descriptor
NEW(p) :        p ------> ---------------
                            field0
                            field1

p.Method() :    p^.typetag^.method_table[no_of_Method]()

When compiling the procedure Foo:
   PROCEDURE Foo(VAR r: R)
the compiler internal procedure header is:
   PROC Foo(VAR r: R; typetag: TypeTag);

r.Method() :      typetag^.method_table[no_of_Method]()

Hope it helps.

-- Alex

----------------------------------------------
Alex Nedorya, Institute of Information Systems



Mon, 20 May 1996 08:22:27 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. graphical representation of types

2. Summary: Representations of Dynamic Type Information

3. Representations of Dynamic Type Information

4. representation(DBL) in waveform data type

5. Summary: Representations of Dynamic Type Information

6. Representations of Dynamic Type Information

7. Summary: Representations of Dynamic Type Information

8. Representations of Dynamic Type Information

9. ASCII representation of data type reg

10. Representation items for a type

11. Newbie question : types , representation

12. Representation Clauses for tagged types

 

 
Powered by phpBB® Forum Software