View mode: basic / threaded / horizontal-split · Log in · Help
April 14, 2008
Core vs Library
http://reddit.com/info/6foi8/comments/
April 14, 2008
Re: Core vs Library
"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?
April 14, 2008
Re: Core vs 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.
April 14, 2008
Re: Core vs Library
"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.
April 14, 2008
Re: Core vs Library
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.
April 17, 2008
Re: Core vs Library
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/
April 25, 2008
Re: Core vs Library
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
May 24, 2008
Re: Core vs Library
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
Top | Discussion index | About this forum | D home