Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1091 > unrolled thread

Re: Safe Pointers at the Intermediate Language or Hardware Level

Back to article view | Back to comp.compilers

Contents

  Re: Safe Pointers at the Intermediate Language or Hardware Level Seima Rao <seimarao@gmail.com> - 2014-02-11 14:35 +0530
    Re: Safe Pointers at the Intermediate Language or Hardware Level Ivan Godard <ivan@ootbcomp.com> - 2014-02-12 14:19 -0800

#1091 — Re: Safe Pointers at the Intermediate Language or Hardware Level

> A safe pointer (cap) is more than 64 bits, and people would refuse to
> repeat the pain of the 32- to 64-bit migration. And most programs
> violate safety (and language standards, but that's another issue), and
> it's hard to make a sale when the customers keep saying "It worked on
> Intel!".

I have a proposal of my own although, I am not sure about the cons and
hence would like to discuss on this forum.


i) All pointers have the same type called pointer_t.

ii) A pointer_t contains the address of a struct whose contents
    are the information relevant to what the pointer is pointing to
   including the type of the element.

There are a lot of questions but the one I am worried about
currently is whether it is possible to have direct HW support.

Sincerely,
Seima Rao.
[You might want to spend a little while learning about the history of
the Burroughs stack architectures.  They did (still do, I guess) all
of this stuff back in the 1960s. -John]

[toc] | [next] | [standalone]

#1092

On 2/11/2014 1:05 AM, Seima Rao wrote:
>> A safe pointer (cap) is more than 64 bits, and people would refuse
>> to repeat the pain of the 32- to 64-bit migration. And most
>> programs violate safety (and language standards, but that's another
>> issue), and it's hard to make a sale when the customers keep saying
>> "It worked on Intel!".
>
> I have a proposal of my own although, I am not sure about the cons
> and hence would like to discuss on this forum.
>
>
> i) All pointers have the same type called pointer_t.
>
> ii) A pointer_t contains the address of a struct whose contents are
> the information relevant to what the pointer is pointing to including
> the type of the element.
>
> There are a lot of questions but the one I am worried about currently
> is whether it is possible to have direct HW support.
>
> Sincerely, Seima Rao.

You can do pretty much anything in hardware. However, the indirection
through the descriptor doubles the latency cost of the dereference and
increases cache demand. Also, keeping track of the type (and if the type
in the descriptor is to be useful then you would need to decorate every
value throughout with type information) is costly, especially as the
number of possible types is unbounded.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web