mosa / mosa-project Goto Github PK

Example from Mosa.Platform.Internal.x86.Runtime::AllocateObject(System.Void*, System.UInt32):

L_0017 X86.Mov V_24 [System.Int32] <= const {0} [System.Int32]
L_0017 X86.Mov [V_7 [System.Int32]+4h] [System.Int32] <= V_24 [System.Int32]

This would be better:

L_0017 X86.Mov [V_7 [System.Int32]+4h] [System.Int32] <= const {0} [System.Int32]

Right now, I need to copy all Mosa.DeviceDrivers and Mosa.DeviceSystem to my project, in other to use them, defeating the purpose of an dll completely.

The MetadataResolver.ResolveMethodOperand trows an exception, because it cannot find the referenced dll file. I'm not familar with dnlib, so can anyone give me a direction how to support this ?

I tried adding them as input files in the Compile method, so I still not understand the moduleLoader.

HelloWorld shows scan codes, but CoolWorld doesn't show reaction on keyboard...
I didn't dig it deeper yet.

I cannot give specifics as I have no idea how its being caused or how to recreate the issue.
This is the best I could come up with to recreate it, you'll need to stub the GetType(string) method in the Type class.
Run it in Explorer.

using System;

public class MyTest 
{
    public bool Test()
    {
            Type bootType = typeof(System.String);
            WRITE(bootType.FullName);
            Type foundType = Type.GetType("System.String");
            if (foundType.Equals(null))
                return false;
            WRITE(foundType.FullName);
            return bootType.Equals(foundType);
    }

    public static void WRITE(string n)
    {
        var a = n;
    }
}

$ mkdir mosa
$ cd mosa
$ git clone https://github.com/mosa/MOSA-Project.git
$ cd mosa/MOSA-Project/Source
$ xbuild
59 Warning(s)
3 Error(s)
Time Elapsed 00:00:43.9652050

/usr/lib/mono/4.0/Microsoft.CSharp.targets (CoreCompile target) ->

    Instructions/Btr.cs(44,4): error CS0162: Warning as Error: Unreachable code detected
    Instructions/Bts.cs(44,4): error  162: Warning as Error: Unreachable code detected

/usr/lib/mono/4.0/Microsoft.CSharp.targets (CoreCompile target) ->

    Boot.cs(172,9): error CS0219: Warning as Error: The variable `a' is assigned but its value is never used

Currently we use large interface bitmap tables to specify whether or not a particular interface is implemented in a class, and this bitmap is the size of the count of interfaces in the entire build.

I propose we change that to use names and place a pointer to the name in the Interface Method Table. This will improve extensibility by allowing the runtime to resolve address to the Metadata.

On a different note, I think we might need to reexamine how some things are resolved as switching to name based resolution will make extensibility easier but will cost more time at startup due to the runtime having to populate lookup tables from the Metadata.

The test cases fail for the production builds, but works for the debug builds.

Missing Mosa.Internal.ExceptionEngine

Are there any ideas on how this should be implemented?
I would like to help any way I can.
I'm currently having to comment out the content of IIRVisitor.Throw to get things to compile since I've used throws in some code I've added to Korlib.

Cheers.

Structs with their layout set to explicit fail to compile.

To reproduce the error run the following code in Explorer:

using System.Runtime.InteropServices;

public class MyTest 
{
        [StructLayout(LayoutKind.Explicit)]
        struct TestStruct
        {
            [FieldOffset(0)]
            uint var1;

            // C# Union
            [FieldOffset(4)]
            float var2;
            [FieldOffset(4)]
            uint var3;
        }
}

NOTE: will require the addition of the FieldOffsetAttribute class to Korlib.

When declaring an object as a static field within itself and initializing it, it will fail to pass all parameters, it always misses the last parameter.

The following code will reproduce the bug in Explorer:

public class MyTest 
{
    public byte Var1;
    public byte Var2;
    public byte Var3;
    public byte Var4;

    public static readonly MyTest Test = new MyTest(0, 0, 0, 0);

    public MyTest(byte var1, byte var2, byte var3, byte var4)
    {
        this.Var1 = var1;
        this.Var2 = var2;
        this.Var3 = var3;
        this.Var4 = var4;
    }
}

The method scanner only compiles methods that are actually by the application. Also, called "tree shake".

Reducing the number of method required to compile an application can significantly shorten the compilation time and memory requirements.

It will also be valuable for low memory platforms.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

LinkedList foreach is broken in master branch.

This is a fairly new (within the last 2 weeks) issue which has sprung up again.

Some quick analysis shows that it has something to do with the fact that it generates Try/Finally blocks.

A quick test of adding the line

 return -1;

inside the foreach loop and running the unit test indicates that it may be an issue with stack offsets.

An Instruction Analysis using Explorer reveals a possible issue with the Exception stage.
It converts this code:

Block #8 - Label L_002F
  Prev: L_0029, L_1000000C
L_002F IR.BlockStart
L_002F IR.FinallyEnd
L_002F IR.BlockEnd
  Next:

into this code:

Block #8 - Label L_002F
  Prev: L_0029, L_1000000C
L_002F IR.BlockStart
L_002F IR.Move EDI [V*] <= V_38 [V*]
L_002F IR.InternalReturn [NULL]
L_002F IR.BlockEnd
  Next: 

which completely bypasses the fact that it should be executing this code:

Block #10 - Label L_0032
  Prev: L_0011
L_0032 IR.BlockStart
L_0032 IR.Nop
L_0033 IR.Return const {-1} [I4] L_7FFFFFFF
L_0033 IR.BlockEnd
  Next: L_7FFFFFFF

Implement a SpinLock class and native platform methods to support a spinlock class.

public struct SpinLock
{
    /// 

    /// Enters spinlock
    /// 
    public void Enter() { }

    /// 

    /// Exits spinlock
    /// 
    public void Exit() { }
}

UInt64Fixture.RemU8U8(a: 18446744073709551614, b: 18446744073709551615)
System.Exception : Aborted. Method did not complete under 100000 ticks.

This appears to be a single edge case failure.

Currently there is no way to reclaim memory in MOSA.
This issue may not seem much of a big deal now but when we get ARM support up and running MOSA may be run in memory constrained environments so it will need to reclaim unused memory or it will run out of memory quite quickly.

Garbage collection in the Runtime will solve this but the issue is how do we implement it?

I propose that for starters we look at using a reference counter implementation as it will be the easiest to implement. I am aware that there are issues with it such as circular reference failure but those are minimal cases which are acceptable for MOSA 1.5.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Add code to emit native ARMv6 opcodes instructions. The target ARM processor is the ARM1176JZF-S used by the Raspberry Pi.

This would involve updating all the instruction classes with opcode sequence and MachineCodeEmitter class in the Mosa.Platform.ARMv6 namespace.

Use the working x86 code as a reference.

There is a $30 open bounty on this issue. Add to the bounty at Bountysource.

When stripping Coolworld of DeviceSystem and DeviceDrivers and adding the equivalent libraries from the kernel folder , a weird issue comes up during compilation.

Failed to locate field Mosa.DeviceSystem.HardwareResources..ctor

If two live intervals are only connected by only a move, the target live interval should, if possible, get the same physical register as the source interval. This can improve code quality by the removing moves.

Further improvement: If the target interval has a fixed physical register interval, the source live range should, if possible, get the same physical register as the target.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

this
https://github.com/ArsenShnurkov/MOSA-Project/tree/d8123bf927a1090088de4770f5b32bfd763863c9
code compiles in monodevelop, but exception occurs during compilation with MOSA compiler:

Done building project "/home/wiwar/github.com/arsenshnurkov/MOSA-Project/Source/MOSA.sln".

Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:05.5213470
MOSA AOT Compiler, Version 1.3 'Neptune'
Copyright 2014 by the MOSA Project. Licensed under the New BSD License.
Copyright 2008 by Novell. NDesk.Options is released under the MIT/X11 license.

Parsing options...

Output file: ./build/main.exe
Input file(s): /home/wiwar/github.com/arsenshnurkov/MOSA-Project/bin/Mosa.CoolWorld.x86.exe
Architecture: Mosa.Platform.x86.Architecture
Binary format: Mosa.Compiler.Linker.Elf32.Elf32
Boot format: Multiboot0695Stage
Is executable: True

Compiling ...

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
at Mosa.Platform.x86.Stages.LongOperandTransformationStage.Mosa.Compiler.Framework.IR.IIRVisitor.Call (Mosa.Compiler.Framework.Context context) [0x00000] in :0
at Mosa.Compiler.Framework.IR.Call.Visit (IIRVisitor visitor, Mosa.Compiler.Framework.Context context) [0x00000] in :0
at Mosa.Compiler.Framework.IR.BaseIRInstruction.Visit (IVisitor visitor, Mosa.Compiler.Framework.Context context) [0x00000] in :0
at Mosa.Compiler.Framework.Context.Visit (IVisitor visitor) [0x00000] in :0
at Mosa.Compiler.Framework.BaseCodeTransformationStage.Run () [0x00000] in :0
at Mosa.Platform.x86.Stages.LongOperandTransformationStage.Run () [0x00000] in :0
at Mosa.Compiler.Framework.BaseMethodCompilerStage.Mosa.Compiler.Framework.IMethodCompilerStage.Execute () [0x00000] in :0
at Mosa.Compiler.Framework.BaseMethodCompiler.Compile () [0x00000] in :0
at Mosa.Compiler.Framework.BaseCompiler.CompileMethod (Mosa.Compiler.MosaTypeSystem.MosaMethod method, Mosa.Compiler.Framework.BasicBlocks basicBlocks, Mosa.Compiler.Framework.InstructionSet instructionSet) [0x00000] in :0
at Mosa.Compiler.Framework.Stages.MethodCompilerSchedulerStage.Run () [0x00000] in :0
at Mosa.Compiler.Framework.BaseCompilerStage.Mosa.Compiler.Framework.ICompilerStage.Execute () [0x00000] in :0
at Mosa.Compiler.Framework.BaseCompiler.Compile () [0x00000] in :0
at Mosa.Tool.Compiler.AotCompiler.Run () [0x00000] in :0
at Mosa.Tool.Compiler.AotCompiler.Compile (Mosa.Compiler.Framework.CompilerOptions compilerOptions, System.Collections.Generic.List1 inputFiles) [0x00000] in <filename unknown>:0 at Mosa.Tool.Compiler.Compiler.Compile () [0x00000] in <filename unknown>:0 at Mosa.Tool.Compiler.Compiler.Run (System.String[] args) [0x00000] in <filename unknown>:0 at Mosa.Tool.Compiler.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object at Mosa.Platform.x86.Stages.LongOperandTransformationStage.Mosa.Compiler.Framework.IR.IIRVisitor.Call (Mosa.Compiler.Framework.Context context) [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.IR.Call.Visit (IIRVisitor visitor, Mosa.Compiler.Framework.Context context) [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.IR.BaseIRInstruction.Visit (IVisitor visitor, Mosa.Compiler.Framework.Context context) [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.Context.Visit (IVisitor visitor) [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseCodeTransformationStage.Run () [0x00000] in <filename unknown>:0 at Mosa.Platform.x86.Stages.LongOperandTransformationStage.Run () [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseMethodCompilerStage.Mosa.Compiler.Framework.IMethodCompilerStage.Execute () [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseMethodCompiler.Compile () [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseCompiler.CompileMethod (Mosa.Compiler.MosaTypeSystem.MosaMethod method, Mosa.Compiler.Framework.BasicBlocks basicBlocks, Mosa.Compiler.Framework.InstructionSet instructionSet) [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.Stages.MethodCompilerSchedulerStage.Run () [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseCompilerStage.Mosa.Compiler.Framework.ICompilerStage.Execute () [0x00000] in <filename unknown>:0 at Mosa.Compiler.Framework.BaseCompiler.Compile () [0x00000] in <filename unknown>:0 at Mosa.Tool.Compiler.AotCompiler.Run () [0x00000] in <filename unknown>:0 at Mosa.Tool.Compiler.AotCompiler.Compile (Mosa.Compiler.Framework.CompilerOptions compilerOptions, System.Collections.Generic.List1 inputFiles) [0x00000] in :0
at Mosa.Tool.Compiler.Compiler.Compile () [0x00000] in :0
at Mosa.Tool.Compiler.Compiler.Run (System.String[] args) [0x00000] in :0
at Mosa.Tool.Compiler.Program.Main (System.String[] args) [0x00000] in :0

See note:

dc85710#commitcomment-6316229

In 32 bit systems
Environment.GetEnvironmentVariable("ProgramFiles(x86)") returns null therefore Path.Combine throws ArgumentNullException.

FILE:
MOSA-Project / Source / Mosa.Utility.Launcher / AppLocations.cs

This file contains helper method CombineParameterAndDirectory, but it is not used everywhere.

The TinySimulator 2BAD bug occurs during unit testing.

Tests will fail with the result 0x2BADB002 which is the magic for Multiboot.

As of yet the cause has not been pinpointed.

SimpleCopyPropagate assertions happen due to IRInstruction.Phi be removed in this PR.

Is this a bug introduced by the PR or is this an existing bug?

I have found that the Mosa compiler cannot handle constructed arrays like the following:

        private static byte[] VGA320x200x4 = new byte[] {
            /* MISC */
            0x63,
            /* SEQ */
            0x03, 0x09, 0x03, 0x00, 0x02,
            /* CRTC */
            0x2D, 0x27, 0x28, 0x90, 0x2B, 0x80, 0xBF, 0x1F,
            0x00, 0x41, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
            0x9C, 0x0E, 0x8F, 0x14, 0x00, 0x96, 0xB9, 0xA3,
            0xFF,
            /* GC */
            0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x02, 0x00,
            0xFF,
            /* AC */
            0x00, 0x13, 0x15, 0x17, 0x02, 0x04, 0x06, 0x07,
            0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
            0x01, 0x00, 0x03, 0x00, 0x00
        };

It will fail with a Unable to determine field size error.

Also fails if the variable isn't static, it seems to be this particular way of constructing the variable.

If the type is changed to object it compiles successfully but is incorrectly sized and will throw an error similar to the following:

Invalid Memory Access at 0x300000

See note:

34a5dfa#commitcomment-6316000

The register allocator generates a move between two memory locations - which is not feasible on the x86. The cause is the register allocator prematurely spills a live interval which is not empty. Only empty live intervals can be spilled.

The exception is caused by an earlier stack corruption.

TinySimulator fails at during ConsoleManager::Setup() with an invalid memory access error.
This error seems to be unique to the simulator since this error doesn't happen in Bochs.

Using an OR operator on enumerators will cause compilation failures of Invalid virtualLocal result of instruction: Unknown

The following code will reproduce the failure in Explorer:

public class MyTest
{
    protected enum F : byte
    {
        First = 0,
        Second = 1
    }

    public void test()
    {
        F fields = 0;
        fields = fields | F.First; // Compiles fine
        fields = fields | F.Second; // Compilation failure
    }
}

As I far as my understanding goes, enums are special value types, but they're still value types. If this is the case then the compiler is incorrectly classifying enums as objects and therein lies the problem.

The LiveIntervalTrack class uses a simple generic List to track live ranges associated with a physical register. For a very small set of ranges, the performance is fast and acceptable. However, for large sets, the performance slows down significantly due to the linear nature.

The List needs to be replaced by a data structure that can perform efficient range searches and the adding & removal of ranges.

When I am trying to start "Run-HelloWorld.sh" (on debian),
the qemu launches,
SYSLINUX 3.72 says "Booting: MBI=0x00010090, entry=0x00400030",
then pink-over-blue text "PANIC! 00000001" appears at the top left corner of qemu window.

The current diagram for Metadata doesn't include custom attributes.

Custom Attributes are a requirement for getting the device drivers working via simple reflection.

My thoughts are to have CustomAttribute Tables with the pointer to the parent and a flag to indicate what the parent is, e.g type, method, etc.

Due to there being rare circumstances where the C# compiler will use the newobj instructions with structs we are getting hard to find bugs throughout MOSA which may be causing stack corruption.

What happens is that whenever the NewObj instruction is used with a struct, the struct is allocated on the Heap not the Stack and MOSA is not currently able to handle that situation.

My solution would be to change how NewObj works so that it instead places structs on to the Stack and modifies the following instructions to treat the struct as Stack based.

I am currently testing this solution.

I am quite unfamiliar with the new type system and it's quite difficult trying to figure out what some of the exceptions mean and why they are being raised.

Any sort of documentation on the meaning of the exceptions, and maybe even an example of when they would be raised, would go a long way towards solving problems with code.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

See #40 and #59
Also take a look at the new Metadata System.

Custom Attributes do not fully support all allowed Attribute parameter/field types as it should. The current MosaCustomAttribute class is inadequate to handle the possibilities.

Add a graphic interface to the MOSA compiler that allows users to select compiler & linker options, select output formats, and then compile and launch a virtual machine. This would augment and reduce the number the existing batch scripts. The goal being to a quick way for new users to experiment and become acquainted with the MOSA project.

As the title says.

Example:
You have class A that implements method M1 from interface I1.
You have another class B that has A as a parent.

If you cast B to type of I1 and try to call method M1 it will not work.

I am currently working on this issue and have added tests with what should be happening.

In the register allocator, virtual registers that are 1) spilled, 2) defined only once, and 3) initial loaded from a method input parameter on the stack and that input parameter is never updated, then 1) skip the spill code which stores the virtual register into a temp location on the stack, and instead 2) re-load the virtual register from the input parameter's stack location.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

We need a stylesheet to transform xunit XML test results into a text file. This allows us to compare changes and improvements over time.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

@tgiphil @kiootic

I have been studying how generics work and I think I have come up with a solution that works just like the CLR runtime.

Every time a generic is used we duplicate the entire tree and replace the generics with either a value type or a special reference pointer.

So when we encounter the instantiation of a generic we simply duplicate it's tree (if there already isn't a duplicate tree with that particular specific) and replace it by the type specified such as int, float, enum, and for reference types we just have a single version for all of them which just has special pointers to the objects.

I think we can manage this through a few simple modifications of the existing type system and adding in a generic-to-specified duplicator which swaps out generics and adds in specifics and marks the duplicated tree as such.

What do you guys think?

I'm looking at starting development on this in July during my semester break.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

A set of virtual registers that are defined only once and loaded from same method input parameter on the stack and that input parameter is never updated, can be folded into a single load.

Example:

In System.String::IndexOfAny(System.Char[])

L_0020 X86.Mov V_6 [System.String] <= this [EBP+4h] [System.String]
L_0021 X86.Mov V_7 [System.Char[]] <= anyOf [EBP+4h] [System.Char[]]
L_0023 X86.Mov V_9 [System.String] <= this [EBP+4h] [System.String]

In this example, the this variable should only be loaded at once into a single virtual register.

The initial load must be placed before all uses from all paths.

A native implementation can place the load in the first block during an early IR stage. This could be helpful for some SSA optimizations.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Hi all,

So the first iteration of Metadata, Runtime and Reflection has been completed and is working fine.
In light of that, I've been looking at how to best implement the rest of the Reflection features and have found that in .NET 4.5 they changed up the model on how it all works by splitting it in two.
The model takes the references and definitions approach where everything in metadata is either a reference of a definition. For example, the Type class would be used for references and would only expose shallow information such as TypeName, while the TypeInfo class would be used for definitions and would expose the in-depth information.

Now, this new model actually seems like a better approach to take as it is simpler and should allow us to implement a lot of Reflection features faster while maintaining portability and performance.
The new model removes a lot of the features existing in the old model but in turn this drastically improves performance (note: in .NET 4.5 they keep they old model as well for backwards compatibility).

What I see happening with the Second Iteration is one of two things:

1. We stick with the classic Reflection model and keep the monolithic sized Reflection API; or
2. We adopt the new .NET 4.5 Reflection model and implement only the new model with none of backwards compatibility.

Thoughts?

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

The MOSA wiki information could use a refresh and re-align to our current goals.

So it seems the ISO image generator isn't working which would be useful as IMG files don't seem to be supported by any of the common VM's such as Hyper-V and VMware.

I think it would be useful to fix the ISO generation for building distributable showcases and building primitive specialized applications using MOSA.