http://reddit.com/info/6foi8/comments/

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:ftv48m$21m5$1@digitalmars.com...
> http://reddit.com/info/6foi8/comments/

1: Yes, in .Net languages the core types are aliases to structs in System, not the other way around.

2: The article seems self-contradictory.  First you say that an int as a struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you turn around and say that modern compilers can make a user-defined complex type efficient.  Which is it?  It doesn't feel like the article comes to any kind of conclusion.  Is it that fundamental types like int and float should be builtin, while anything higher-level including complex can be done satisfactorily as a library?

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:ftv48m$21m5$1@digitalmars.com...
>> http://reddit.com/info/6foi8/comments/
> 
> 1: Yes, in .Net languages the core types are aliases to structs in System, not the other way around.


I don't buy it. The C# compiler somewhere in it knows what an int is, after all, divides aren't done by a subroutine somewhere, they're done by a hardware instruction.

If you don't agree, show me how System.Int32 can be implemented without referring to a core int type.


> 2: The article seems self-contradictory.  First you say that an int as a struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you turn around and say that modern compilers can make a user-defined complex type efficient.  Which is it?  It doesn't feel like the article comes to any kind of conclusion.  Is it that fundamental types like int and float should be builtin, while anything higher-level including complex can be done satisfactorily as a library?

The struct can be optimized if it is based upon *core* types that can be optimized.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fu0bb5$1sa1$1@digitalmars.com...

>> 1: Yes, in .Net languages the core types are aliases to structs in System, not the other way around.
>
>
> I don't buy it. The C# compiler somewhere in it knows what an int is, after all, divides aren't done by a subroutine somewhere, they're done by a hardware instruction.
>
> If you don't agree, show me how System.Int32 can be implemented without referring to a core int type.

It's not that the C# compiler knows what an int is, it's how the .net runtime represents them.  As far as the C# type system is concerned, 'int' and 'System.Int32' are one and the same.  If you could do "typeof(5)" in C# it'd yield System.Int32.  System.Int32 is a value type, one of the builtin types in the .net runtime.  Being a value type, it is allocated on the stack, passed by copy, all the things you'd expect.

When a .net high-level language compiler (like the C# compiler) emits code, it's emitting CLR, not x86.  If it emits a "div" instruction with two values of type System.Int32 as its parameters, the JIT compiler then has the opportunity to optimize that down to a single x86 "idiv" instruction rather than making a subroutine call.  However, System.Int32s, being object types, can still participate in object-like behavior - they can have methods and such.

Remember that codegen in .net languages is a 2-step process, and as such, the high-level language compiler is not really the one that has to deal with low-level representation, even of basic types like int.

> The struct can be optimized if it is based upon *core* types that can be optimized.

OK.

Jarrett Billingsley wrote:
> It's not that the C# compiler knows what an int is, it's how the .net runtime represents them.  As far as the C# type system is concerned, 'int' and 'System.Int32' are one and the same.  If you could do "typeof(5)" in C# it'd yield System.Int32.  System.Int32 is a value type, one of the builtin types in the .net runtime.  Being a value type, it is allocated on the stack, passed by copy, all the things you'd expect.
> 
> When a .net high-level language compiler (like the C# compiler) emits code, it's emitting CLR, not x86.  If it emits a "div" instruction with two values of type System.Int32 as its parameters, the JIT compiler then has the opportunity to optimize that down to a single x86 "idiv" instruction rather than making a subroutine call.  However, System.Int32s, being object types, can still participate in object-like behavior - they can have methods and such.

The CLR has a special 'int32' data type. See the spec for it:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf
section 8.2.2


> Remember that codegen in .net languages is a 2-step process, and as such, the high-level language compiler is not really the one that has to deal with low-level representation, even of basic types like int.

It still recognizes it as a special, core type.

What is happening is that C# does automatic boxing/unboxing of value types. See 8.2.4.

It looks like Int32 defined as follows:
(output from Reflector)

public struct Int32 : IComparable, IFormattable, IConvertible, IComparable<int>, IEquatable<int>
{
    internal int32 m_value; // here it is!

    public const int MaxValue = 0x7fffffff;
    public const int MinValue = -2147483648;
    public int CompareTo(object value);
    public int CompareTo(int value);
    public override bool Equals(object obj);
    public bool Equals(int obj);
    public override int GetHashCode();
    public override string ToString();
    public string ToString(string format);
    public string ToString(IFormatProvider provider);
    public string ToString(string format, IFormatProvider provider);
    public static int Parse(string s);
    public static int Parse(string s, NumberStyles style);
    public static int Parse(string s, IFormatProvider provider);
    public static int Parse(string s, NumberStyles style, IFormatProvider provider);
    public static bool TryParse(string s, out int result);
    public static bool TryParse(string s, NumberStyles style, IFormatProvider provider, out int result);
    public TypeCode GetTypeCode();
    bool IConvertible.ToBoolean(IFormatProvider provider);
    char IConvertible.ToChar(IFormatProvider provider);
    sbyte IConvertible.ToSByte(IFormatProvider provider);
    byte IConvertible.ToByte(IFormatProvider provider);
    short IConvertible.ToInt16(IFormatProvider provider);
    ushort IConvertible.ToUInt16(IFormatProvider provider);
    int IConvertible.ToInt32(IFormatProvider provider);
    uint IConvertible.ToUInt32(IFormatProvider provider);
    long IConvertible.ToInt64(IFormatProvider provider);
    ulong IConvertible.ToUInt64(IFormatProvider provider);
    float IConvertible.ToSingle(IFormatProvider provider);
    double IConvertible.ToDouble(IFormatProvider provider);
    decimal IConvertible.ToDecimal(IFormatProvider provider);
    DateTime IConvertible.ToDateTime(IFormatProvider provider);
    object IConvertible.ToType(Type type, IFormatProvider provider);
}


On Tue, 15 Apr 2008 00:46:50 +0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:

> "Walter Bright" <newshound1@digitalmars.com> wrote in message
> news:fu0bb5$1sa1$1@digitalmars.com...
>
>>> 1: Yes, in .Net languages the core types are aliases to structs in
>>> System, not the other way around.
>>
>>
>> I don't buy it. The C# compiler somewhere in it knows what an int is,
>> after all, divides aren't done by a subroutine somewhere, they're done by
>> a hardware instruction.
>>
>> If you don't agree, show me how System.Int32 can be implemented without
>> referring to a core int type.
>
> It's not that the C# compiler knows what an int is, it's how the .net
> runtime represents them.  As far as the C# type system is concerned, 'int'
> and 'System.Int32' are one and the same.  If you could do "typeof(5)" in C#
> it'd yield System.Int32.  System.Int32 is a value type, one of the builtin
> types in the .net runtime.  Being a value type, it is allocated on the
> stack, passed by copy, all the things you'd expect.
>
> When a .net high-level language compiler (like the C# compiler) emits code,
> it's emitting CLR, not x86.  If it emits a "div" instruction with two values
> of type System.Int32 as its parameters, the JIT compiler then has the
> opportunity to optimize that down to a single x86 "idiv" instruction rather
> than making a subroutine call.  However, System.Int32s, being object types,
> can still participate in object-like behavior - they can have methods and
> such.
>
> Remember that codegen in .net languages is a 2-step process, and as such,
> the high-level language compiler is not really the one that has to deal with
> low-level representation, even of basic types like int.
>
>> The struct can be optimized if it is based upon *core* types that can be
>> optimized.
>
> OK.
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Jarrett Billingsley wrote:
>  However, System.Int32s, being object types, can still participate in object-like behavior - they can have methods and such.
> 

Being "object-like", and having methods and such, does not make a type a library type (in the sense of Core vs. Library).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright a écrit :
> http://reddit.com/info/6foi8/comments/

I've seen on lambda the ultimate some research paper where they tried to put optimisation as a part of the standard library..

So maybe the core vs library will change in the future if these research  works out (unlikely but not impossible).

Regards,
renoX