dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pnet-developers] Use of ILNativeUInt vs. unsigned long in pointer c


From: Miroslaw Dobrzanski-Neumann
Subject: Re: [Pnet-developers] Use of ILNativeUInt vs. unsigned long in pointer casting and manipulation
Date: Mon, 27 Sep 2004 10:08:17 +0200
User-agent: Mutt/1.5.6i

On Fri, Sep 24, 2004 at 04:58:58PM +1000, Rhys Weatherley wrote:
> On Friday 24 September 2004 04:32 pm, Miroslaw Dobrzanski-Neumann wrote:
> 
> > *Do not reuse pointer for anything else*
> 
> Or rather, understand what bits of a pointer really are static.
> 
> The m68k assumption was based on "no one would ever have more than 16 Mb of 
> memory", which is just as dumb as "two digit years will be good enough for 
> everybody".
> 
> My assumption is "a pointer to a machine word is guaranteed to have the 
> bottom 
> two bits set to zero".  I've yet to come across a machine that breaks this 
> assumption and which cannot be adjusted through the use of malloc hacks.
> 
> Feel free to provide a counter-example.  In the worst case, a few macros in 
> il_types.h may need #ifdef'ing if the "spare bits" aren't at the bottom 
> (Peter and I already solved this for the 16-byte pointers in AS/400, but the 
> 16-byte port failed for other reasons).
> 
> > What does pnet mean? "portable .net"?
> 
> Portable to every platform that isn't terminally bletcherous.  We can't run 
> on 
> m68k PalmOS because of a 64k limitation on code size, the ultra-dumb non-flat 
> memory model that m68k PalmOS uses, and the lack of a useful libc.  Is that a 
> bug in pnet, or merely a design trade-off?  Some platforms are so horrid that 
> "write your own CLI from scratch" is the only viable answer to "will pnet run 
> on this?".
> 
> > > > to get a new platform.  It is that simple.
> >
> > I do not believe it ist the portable option.
> 
> I look forward to your patch. :-)

struct ILType;
struct ILTypeVTBL
{
        ...
        char const *(* GetName)   (struct ILType *);
        BOOL        (* IsComplex) (struct ILType *);
        ...
};

struct ILType
{
        ILTypeVTBL *vtbl;
        ...
};

struct ILTypeVTBL ILTypeVTBL_Primitive =
{
        &ILTypeVTBL_Primitive_GetName,
        &ILTypeVTBL_IsComplex,
        ...
}

struct ILType ILType_Void =
{
        &ILTypeVTBL_Primitive,
        ...
};

static inline BOOL ILType_ISPrimitive (ILType *type)
{
        return ILTypeVTBL_Primitive == type->vtbl;
}
...

static inline ILType_Void *ILType_Void_DOWNCAST (ILType *type)
{
        ASSERT (&ILType_Void == type);
        return (ILType_Void *)type;
}

...
static inline BOOL ILType_IsArray (ILType *type)
{
        return NULL != type && &ILTypeVTBL_Array == type->vtbl;
}

static inline ILType_Array *ILType_Array_DOWNCAST (ILType *type)
{
        ASSERT (&ILTypeVTBL_Array == type->vtbl);
        return (ILType_Array *) type;
}


This way you do not have to shift any bits neither make assumptions about how
a pointer is beeing represented.
I believe that pointer dereferencing and comparison costs not more then bit
shifting and masking.

Please look at glib if you want a foundation for an OO typesystem in C

Regards,
--
Mirosław Dobrzański-Neumann
E-mail: address@hidden

This message is utf-8 encoded


reply via email to

[Prev in Thread] Current Thread [Next in Thread]