Core vs Library

[Jarrett Billingsley]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:fu0bb5$1sa1$1 at 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.