Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 24 06:59
    tgiphil edited #807
  • Oct 24 03:48

    tgiphil on 139-progress

    - Progress - Progress - Progress (compare)

  • Oct 24 01:29

    tgiphil on master

    New IR Instructions to support … (compare)

  • Oct 24 01:29
    tgiphil closed #808
  • Oct 24 01:27
    tgiphil labeled #808
  • Oct 24 01:27
    tgiphil opened #808
  • Oct 24 01:27
    tgiphil milestoned #808
  • Oct 24 01:15

    tgiphil on 138-loadobject

    - Progress - New IR instructions to separa… (compare)

  • Oct 20 07:41

    tgiphil on 137-arm

    - More Optimizations (compare)

  • Oct 20 07:25

    tgiphil on 137-arm

    Create CNAME Optimizations (#807) * - Progr… - Add another optimization vari… and 1 more (compare)

  • Oct 20 02:12

    tgiphil on master

    Optimizations (#807) * - Progr… (compare)

  • Oct 20 02:12
    tgiphil closed #807
  • Oct 20 02:02
    tgiphil assigned #807
  • Oct 20 02:02
    tgiphil opened #807
  • Oct 20 02:02
    tgiphil labeled #807
  • Oct 20 02:02
    tgiphil milestoned #807
  • Oct 20 01:52

    tgiphil on master

    Create CNAME (compare)

  • Oct 20 01:41

    tgiphil on 136-arm

    - Progress (compare)

  • Oct 19 06:42

    tgiphil on 136-arm

    - Progress - Progress (compare)

  • Oct 19 00:24

    tgiphil on 136-arm

    - Merged LongOperationStage int… (compare)

Phil Garcia
@tgiphil
G’morning!
Phil Garcia
@tgiphil
@furesoft The OS Name is now configurable within the Launcher tool
Stefan Andres Charsley
@charsleysa
@tgiphil saw this in your latest PR, is there a bug or am I misunderstanding what the comment means:
            return new AddressRange(BootReservedAddress, (Page.Size * (32 + 32)));    // 4GB = 32 (on x86), 2GB = 16 (on x64), 64GB = 16 * 32
John
@djlw78
@tgiphil what about file config? like adding files to file system?
Phil Garcia
@tgiphil
@charsleysa Yeah, ignore the comment.
@djlw78 I didn't get to that. Do you want to tackle that?
Phil Garcia
@tgiphil
I was thinking of a simple include like this:
#Source    Destination
root    /        # includes all directors and files under root
fonts/*.fnt    /font    # includes fonts
John
@djlw78
well, yeah uh. idk how to execute it
Phil Garcia
@tgiphil
and with the following two setting options:
Image.FileSystem.IncludeFile
Image.FileSystem.SourceFolder
Well, first -- those two options are added --- both are strings
When the launcher reads the include file, and creates an IncludeFile object for each file and pass it to the bootImageOptions.IncludeFiles list
bootImageOptions.IncludeFiles.Add(new IncludeFile("ldlinux.sys", GetResource(@"syslinux\6.03", "ldlinux.sys")));
bootImageOptions.IncludeFiles.Add(new IncludeFile("TEST.TXT", Encoding.ASCII.GetBytes("This is a test file.")));
most of the changes go into Mosa.Utility.Launcher.Builder
John
@djlw78
AH
sorry was soldering
Phil Garcia
@tgiphil
I opened an issue for this: mosa/MOSA-Project#802
Imperatorn
@Imperatorn
PS MOSA rox DS
Phil Garcia
@tgiphil
@Imperatorn ??
Sergei Pogrebniak
@TheSergePage
Hello lads
Phil Garcia
@tgiphil
Hello!
Phil Garcia
@tgiphil
Can anyone explain the difference between scalar and vector values on the arm platform? Thanks!
Stefan Andres Charsley
@charsleysa
@tgiphil I think vectors are just a way of grouping registers for SIMD
Phil Garcia
@tgiphil
I'm trying to find the difference between the fmov scalar and vector versions.
Essentially a vector is a SIMD 128bit register split into multiple units, e.g. Four 32bit elements
GeroL
@GeroL
Hi, I am currently switching mosa projects to use .Net 5 and try to get rid of .Net 4.72. The tools work good so far and also the compiler etc. I also try a different plugs/korlib system using the .net core system where compile and runtime is splitted. Currently I use the app framework facade to compile mosa kernels. i used a custom framework target for this (mosa-x86 instead of win-x86). Now i wanted to use the coreclr system.private.corelib as a replacement for korlib. Using the explorer tool I hit some obstacles here. first there are FnPtr types which mosa can't compile yet. As I understand these are function pointers to internal calls which are normally implemented in C++. So this type would be a good candidate to be remodeled as a plug, am I right here?
dnlib reads the metadata of that first delegate parameter as (fnptr), <<<NULL>>>
GeroL
@GeroL
nvm. I worked around this for now
Stefan Andres Charsley
@charsleysa
@GeroL I've also been exploring how to upgrade to net5 for the OS code as well. I came to the conclusion that a custom version of system.private.corelib was required as the pre-compiled versions are OS-and-platform-specific using OS APIs. Did you find a different solution?
Phil Garcia
@tgiphil
Hi! I’ll respond tonight!
GeroL
@GeroL
@charsleysa yes, I pretty certain that must be done. cloned the coreclr repo and try to create a runtime.mosa-x86 package there which will should be used as runtime reference. I try to get that somehow working. All platforms have their own but i use the windows version as a start.
Stefan Andres Charsley
@charsleysa
@GeroL I have started some work on creating a custom version of the corelib library, it's a pretty complicated process and so far have had to hack their build chain into the MOSA solution. I have it almost completely compiling. Once I have it completely compiling the last step should be actually integrating the lib with our runtime.
Phil Garcia
@tgiphil
@charsleysa Awesome!
GeroL
@GeroL
It takes ages to resolve everything in the mscorlib :( I made it multithreaded but it needs much more ram now. the data should be cached to a DB or something with full results and only a reference should remain in memory.
My plan is that we can reuse as much as possible from .net without changing anything. The mosa tools should link plugs together and replace the calls where needed.
GeroL
@GeroL
the runtime I use will publish a nuget package. thats how .net core resolves the runtime https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders
Stefan Andres Charsley
@charsleysa
@GeroL most of the net5 core libraries can be reused without modification as they are considered universal, but the system.private.corelib library integrates deeply with the os linking into os-specific native libraries and also being internally optimized with inlining in such a way that I think it would be very difficult if not impossible to convert only using mosa tools.
A large part of system.private.corelib source is actually shared so most of it doesn't need to be modified, we just need to add the missing parts for our mosa specific version (which is the approach net5 itself takes when building the core libraries for different OSs)
GeroL
@GeroL
Correct. I try to get a POC running that we can just use that lib as it is along with some sort of easy to use plug system which implement the native calls into the vm etc. The calls to native or OS libs are all marked as extern call or dllimport, etc. I think it should not be a problem to identify these and just insert a call to a plug there right?
Stefan Andres Charsley
@charsleysa
Possibly, there is assumptions used when compiling for a particular OS that is essentially hardcoded into the corelib (e.g. path separator is \ for windows and / for unix), so we would have to find all those locations and create replacements for every location, which may end up being a lot more work than compiling a custom version of the corelib
Phil Garcia
@tgiphil
The other issue, which I have not studied much, is that elements in system.private.corelib have a deep understanding of the internal data structures --- sync blocks, metadata. So we also need to match those specific implementation details.
Stefan Andres Charsley
@charsleysa
@tgiphil yes, that is indeed the case, though with a custom corelib some of those issues can be mitigated by either:
a) not supporting them (for now or possibly at all)
b) converting between our structure to their structure
c) upgrading our runtime to match their requirements
GeroL
@GeroL
@tgiphil That is especially true for the Thread. Although I think that in the long term there will be 2 runtimes. One for the OS itself and one for applications running inside the os.
However I believe that the only feasible way is using the code from .net core without modifications and building something around or it because otherwise we will be cut off from its development and developers have to know too much details on how the mosa runtime differs from the normal .net runtime.
GeroL
@GeroL
That said and together with the results of my experiments with the resolver earlier, I try to create a very stripped version of the CoreLib matching the current korlib to get my idea working. If that should work the mosa runtime corelib could be developed as an independent project.
Stefan Andres Charsley
@charsleysa
@GeroL the way I solve the sync with the dotnet repo is by adding the dotnet repo as a git submodule and linking to a specific branch (in this case the net5 release branch), this cuts down the amount of custom code required to just the mosa specific code as the rest is shared code which is simply included into the project
GeroL
@GeroL
@charsleysa I thought of that, too. There is also the git subtree thing but in the end I am just interested in the lib for now. Do you have that code on github? May I have a look there?
Stefan Andres Charsley
@charsleysa
@GeroL I've pushed my work in progress to github, the corelib should compile but fail to run through the entire buildchain and result with an IL1005 error
https://github.com/charsleysa/MOSA-Project/tree/feat-dotnet-runtime
Phil Garcia
@tgiphil
Great work!