pointed pointer questions

djones@megatest.uucp (Dave Jones)
15 Jul 88 03:06:30 GMT

          From comp.compilers

Related articles
pointed pointer questions djones@megatest.uucp (1988-07-15)
| List of all articles for this month |

From: djones@megatest.uucp (Dave Jones)
Newsgroups: comp.compilers,comp.lang.pascal
Keywords: pointer Pascal compiler
Date: 15 Jul 88 03:06:30 GMT
Organization: Megatest Corporation, San Jose, Ca

Let us speak of pointers and alignment. Here's your chance to
show off your knowledge of machine architectures and
compiler theory. Impress your friends. Win new followers....


The purpose of the exercise is to define a virtual machine compatible
on the one side with Pascal, and on the other with any reasonable
hardware. The traditional P-machine comes up a little short when
it comes to pointer arithmetic. As you probably know, there are
some machines that store pointers to integers in 13 1/2 bit
interleaved nybbles, and pointers to functions in Best Foods Mayonaise
jars -- at least it seems that bizzarre.


(What kind of punishment is appropriate for the designers
of such systems is another subject intirely.)


So question number one is, to be safe, how many kinds of pointers
should the virtual machine have? If you define them according to
the Pascal types, you get TEN of them for Pete's sake!


    /* pointers to Pascal primitive types */
    PTR_REAL,
    PTR_INT,
    PTR_CHAR,
    PTR_BOOL,


    /* pointers to Pascal constructed types */
    PTR_FILE,
    PTR_PTR,
    PTR_ARRAY,
    PTR_STRUCT,
    PTR_ENUM,


    /* pointers to functions and procedures */
    /* (For procedure-valued parameters) */
    PTR_FUNC


Which of these can safely be folded together? How many do I *really*
need, and what are they?


It is possible (at least in BSD-derived Pascals) to pass components of
records as var-parameters.


This means that the virtual machine must have a way to convert
a structure-pointer and a field-displacement into any kind of
pointer. To convert to the first nine of the pointer-types listed above,
the op-codes proliferate in a sickening fashion:


    FIELD_REAL, /* returns pointer to real */
    FIELD_INT, /* returns pointer to int, etc.. */
    FIELD_CHAR,
    FIELD_BOOL,
    FIELD_FILE,
    FIELD_STRUCT,
    FIELD_ARRAY,
    FIELD_ENUM,


    FIELD_PTR_ENUM, /* returns pointer to pointer enum */
    FIELD_REAL_PTR, /* etc. */
    FIELD_INT_PTR,
    FIELD_CHAR_PTR,
    FIELD_BOOL_PTR,
    FIELD_FILE_PTR,
    FIELD_STRUCT_PTR,
    FIELD_ARRAY_PTR,
    FIELD_PTR_PTR,


I am tempted to boot the whole idea, and just say there is one
kind of pointer: a thirty-two bit word. And we will burn all
the the computers that don't behave that way.


Another idea is to have a mapping between Pascal-pointer types
and machine-pointer types that can be redefined for different kinds
of hardware. The question then is, "What set of machine-pointer
types is sufficient to keep the most berzerk system designer appeased?"


[From djones@megatest.uucp (Dave Jones)]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.