Support for AnyCPU

[jlarsson]

Support for AnyCPU can be enabled by

1. create platform target AnyCPU based on x64
2. modifying platform dependent definitions to a generic default (i.e. 64 bit aligment)
   Currently,this would only be BoxedValueOffests in Runtime.fs.
   Below is a proposed change

module BoxedValueOffsets =
#if X64
let [] ValueType = 8
let [] Tag = 12
let [] Marker = 14
#else
#if X86
let [] ValueType = 4
let [] Tag = 8
let [] Marker = 10
#else
let [] ValueType = 8
let [] Tag = 12
let [] Marker = 14
#endif
#endif

[otac0n]

I'm not sure that this is the best way to support AnyCPU. Rather, I think that we should change the order of the field offests, and make the value types come first (with an offset of 0) since Bool and Double have guarantees about their length in the Spec.

Something like:

module BoxedValueOffsets =
  let [<Literal>] ValueType = 0
  let [<Literal>] Tag = 4
  let [<Literal>] Marker = 6
  let [<Literal>] ReferenceType = 8

// Value Types
[<FieldOffset(BoxedValueOffsets.ValueType)>] val mutable Bool : bool
[<FieldOffset(BoxedValueOffsets.ValueType)>] val mutable Number : double

// Type & Tag
[<FieldOffset(BoxedValueOffsets.Tag)>] val mutable Tag : uint32
[<FieldOffset(BoxedValueOffsets.Marker)>] val mutable Marker : uint16

// Reference Types
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable Clr : Object
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable Object : CO
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable Array : AO
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable Func : FO
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable String : string
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable SuffixString : SuffixString
[<FieldOffset(BoxedValueOffsets.ReferenceType)>] val mutable Scope : BV array

[otac0n]

I would absolutely love to get away from separate X86 and X64 builds, if that is possible, but I have to defer to Fredrik on this one, since I don't know the nuances of the Boxing as well as he does.

If we do this, I will immediately get a build of the project up on NuGet, since this was the primary reason for holding off.

[ChaosPandion]

We may want to start using discriminated unions to circumvent the issue completely. From an API perspective this shouldn't be a major change. However the performance benefits of tagged unions are currently unknown to me from within a managed language.

[fholm]

@ChaosPandion: We have to use this struct because of the performance implications of using a tagged union,this struct is the fastest possible way to do dynamic typing within the DLR

[otac0n]

@fholm: Are my changes feasible? I'm running the tests right now, but I cant test for regressions, since I hadn't run the tests before on this machine. (And, I have no access to the tests on my home computer right now, either.)

[otac0n]

(Sorry, Github auto-closed the issue.)

I have run the Sputnik tests, and there were no regressions. I have also reconfigured the solution and project files to reflect the unified processor format.

@fholm, I'll let you make the decision on whether to merge this into master.

[otac0n]

@jlarsson, we have made the update. I have also pushed it to NuGet! Whee!

[jlarsson]

Ty guys. It works like a charm with NuGet.

[axefrog]

Thanks for the update! Now I can move over from Jint :)