by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 22:23
  • Jan 31 2019 22:00
    MichalStrehovsky commented #6919
  • Jan 31 2019 21:59
    MichalStrehovsky opened #6928
  • Jan 31 2019 20:45
  • Jan 31 2019 19:57
    kouvel commented #6880
  • Jan 31 2019 19:45
    filipnavara commented #6880
  • Jan 31 2019 19:44

    jkotas on master

    Merge pull request #6815 from d… Merge pull request #6839 from d… Merge pull request #6859 from d… and 8 more (compare)

  • Jan 31 2019 19:44
    jkotas closed #6926
  • Jan 31 2019 19:43
    kouvel commented #6880
  • Jan 31 2019 19:26
    kouvel commented #6880
  • Jan 31 2019 19:19

    trylek on master

    Pointer size and ARM64 fixes in… (compare)

  • Jan 31 2019 19:19
    trylek closed #6921
  • Jan 31 2019 18:40
    jkotas synchronize #6926
  • Jan 31 2019 18:40

    jkotas on nmirror

    MethodOnStruct - Fixing Project… Merge pull request #6927 from d… (compare)

  • Jan 31 2019 18:40
    jkotas closed #6927
  • Jan 31 2019 18:32
    dotnet-bot opened #6927
  • Jan 31 2019 17:19

    jkotas on master

    Reverting "Fixing up the UTF8Fo… Add managed implementation of G… (compare)

  • Jan 31 2019 17:19
    jkotas closed #6923
  • Jan 31 2019 17:18

    jkotas on master

    Fix ProjectN build breaks (#692… (compare)

  • Jan 31 2019 17:18
    jkotas closed #6924
Robin Sue
@Suchiman
@Alan-FGR a function pointer is a single address that can be indirectly invoked and is pointer sized. A delegate is a heap object that is a tuple of function and target (instance pointer). So you can pass to c code a function pointer that is expected to be called like a static function and the CLR will provide a static delegate thunk (IIRC the terminology) that secretly adds the this pointer and invokes the instance method
Alan
@Alan-FGR
right, but shouldn't the UnmanagedFunctionPointer attribute turn the delegate into a function pointer? Maybe the problem is that attribute isn't implemented in CoreRT?
Robin Sue
@Suchiman
@Alan-FGR well that's the marshalling magic and i've meant that this doesn't just work, this is a lot of runtime effort to make it work, or a lot of things that could break :P
Alan
@Alan-FGR
I don't understand @Suchiman, so that attribute has to do with marshalling, it doesn't actually turn the C# delegate into a function pointer? there's still the other delegate stuff under the hood there?
C# delegates are kinda collections too right?
Alan
@Alan-FGR
actually, it seems UnmanagedFunctionPointer inly really changes the call convention tbh
if that's the case then my code was indeed incorrect, but it's still very strange that it worked fine on netfx and coreclr
Robin Sue
@Suchiman
@Alan-FGR yes, UnmanagedFunctionPointer is only a hint to the marshaller
Alan
@Alan-FGR
ok, thanks @Suchiman... still, there's inconsistency between CoreCLR and CoreRT there
what the code was doing before was actually converting the native function pointer into a delegate and then the delegate was being called and was calling the function pointer, what's not only wrong (because the signature wasn't impl) but it's terrible in terms of perf too
i mean, if you get a function pointer from native and marshal it into a delegate, it's actually going to add that function to the delegate collection kinda thing i guess... the delegate will store the pointer to the native function, it won't be the native function
Alan
@Alan-FGR
that kinda makes sense tbh, otherwise that attribute would have to break delegates default behavior
troll-kadabra
@troll-kadabra
alan does it work on ubuntu
Alan
@Alan-FGR
it should, on mono/coreclr i'm pretty sure it will, corert binaries i don't know :P
troll-kadabra
@troll-kadabra
where can i see corert state on linux
@Alan-FGR make c# engine plz :p
Alan
@Alan-FGR
@troll-kadabra i'll eventually roll out some minECS systems, but probably not a fully featured game engine, at most some level editors and whatnot perhaps
first I gotta finish minECS though :trollface:
Yair Halberstadt
@YairHalberstadt
I'm trying to find out what CoreRT is used for currently, but I can't find much in brief Google Search. Can anyone here shed light on that? Thanks.
Robin Sue
@Suchiman
@YairHalberstadt well CoreRT is an experimental AOT runtime
@YairHalberstadt but it's used in some form for .NET native (UWP) i believe
Yair Halberstadt
@YairHalberstadt
Ok, so not much at the moment?
Robin Sue
@Suchiman
yes
Michal Strehovský
@MichalStrehovsky
@YairHalberstadt .NET Native (the ARM64 version specifically) is pretty much CoreRT, but with added WinRT interop support and a more powerful code generator backend: the runtime, class libraries and garbage collector are the same, and much of the compiler is the same too (except for the code generation part). So all UWP .NET apps run on "CoreRT++"
The vanilla open source CoreRT is not officially supported, so we don't have much data. SoundFlow.org uses it in their macOS client, for example: https://twitter.com/chrscheuer/status/1110836852016193536
masonwheeler
@masonwheeler
Hmm... what cool extra codegen stuff does the .NET Native system have, and what's stopping it from being added to CoreRT?
Michal Strehovský
@MichalStrehovsky
.NET Native uses UTC as the code generation backend. It's the same code generation backend that Visual C++ uses. It's closed source and can only target Windows
masonwheeler
@masonwheeler
*nod*
Yair Halberstadt
@YairHalberstadt
Thanks. So is .Net Native built on CoreRT, or CoreRT is extracted from .Net Native?
Robin Sue
@Suchiman
@MichalStrehovsky what's the deal with ARM64 in particular? Is this not true for x86 / x64?
Michal Strehovský
@MichalStrehovsky
@YairHalberstadt ~95% of the source code in the CoreRT repo is also used in .NET Native. .NET Native adds a couple extra things
@Suchiman ARM64 came to .NET Native as a supported platform last year, so we decided to reuse the ILCompiler for that. This article describes .NET Native compilation a bit. For ARM64, we no longer do the "Compiling to MDIL" and "Native binding" step. Instead, we use pieces of the CoreRT ILCompiler, generate object files, and link them with the platform linker. Migrating the rest of the architectures to the same plan is a cost/benefit exercise
Robin Sue
@Suchiman
ah interesting
Yair Halberstadt
@YairHalberstadt
So updates to CoreRT eventually end up in .Net Native
And hence UWP
And so CoreRT isn't really experimental from that perspective? Changes to it will end up in production?
Anyway thanks for the info
Alan
@Alan-FGR
hey guys, so again people aren't able to build the core project because of the corert package include (https://github.com/Alan-FGR/SharpPhysX/blob/4e356b308878fa368a8763575c1421b798d2a033/Samples.Core/Samples.Core.csproj#L74), is there no decent way to add a conditional on that?
i thought that maybe checking whether solutiondir exists, that would at least fix building coreclr from the VS i guess
it's very frustration to people when stuff does not build and work outta the box
Robin Sue
@Suchiman
@Alan-FGR what?
what's the problem with that include?
Alan
@Alan-FGR
the problem is that breaks building from VS
if you don't have that include installed and try to open the solution in VS and build a net core binary it'll just complain that the ilcompiler thing isn't installed and abort
ahopper
@ahopper

@Alan-FGR I use

<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="1.0.0-alpha-27619-01" Condition="'$(CoreRT)' == 'True'" />

and then dotnet publish -r win-x64 -c release -f netcoreapp3.0 /p:CoreRT=True

Alan
@Alan-FGR
@ahopper wow, i didn't know you could pass a condition like that, thank you :smiley:
ahopper
@ahopper
I think I got it from @wieslawsoltes
Wiesław Šoltés
@wieslawsoltes
I also do this :
  <PropertyGroup>
    <CoreRT>False</CoreRT>
  </PropertyGroup>
  <PropertyGroup Condition="'$(RuntimeIdentifier)' == 'win-x64'">
    <CoreRT>True</CoreRT>
    <DefineConstants>$(DefineConstants);_CORERT;_CORERT_WIN_X64</DefineConstants>
  </PropertyGroup>
  <PropertyGroup Condition="'$(RuntimeIdentifier)' == 'linux-x64'">
    <CoreRT>True</CoreRT>
    <DefineConstants>$(DefineConstants);_CORERT;_CORERT_LINUX_X64</DefineConstants>
  </PropertyGroup>
  <PropertyGroup Condition="'$(RuntimeIdentifier)' == 'osx-x64'">
    <CoreRT>True</CoreRT>
    <DefineConstants>$(DefineConstants);_CORERT;_CORERT_OSX_X64</DefineConstants>
  </PropertyGroup>
or this:
  <ItemGroup Condition="'$(RuntimeIdentifier)' == 'win-x64' or '$(RuntimeIdentifier)' == 'linux-x64' or '$(RuntimeIdentifier)' == 'osx-x64'">
    <RdXmlFile Include="Draw2D.rd.xml" />
    <PackageReference Include="Microsoft.DotNet.ILCompiler" Version="1.0.0-alpha-*" />
  </ItemGroup>