Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Dexter Dexter
  • IL to C++ compiler - Need advice on implementing context switching

    I wonder if it has something to do the the "dup" instructions.

    Yep. If you look at the generated code for IL3A-3F you can easily note that dup has no effect. If you remove the dup then your compiler would generate identical code. That's a good indication that something isn't right.

    So when I perform the dup operation, the two top items on the stack now contain "pStr".

    dup make a copy of the value, it seems to me that your implementation makes a copy of some sort of reference to the value.

  • IL to C++ compiler - Need advice on implementing context switching

    A better but more difficult solution: Any structs that have ref type fields also get the same hard-coded functions to manage their pointers just like classes get

    That sounds good. And I might have a slightly different idea, treat the stack frame as objects:

    • for each method create a struct that contains all the method parameters and locals
    • when you call a method allocate such a struct on the stack (by using alloca or other means)
    • fill the parameters
    • call the method with a pointer to the allocated struct
    • you'll also need to store pointers to these stack frames on that virtual stack of yours or simply chain the stack frames into a linked list (pointed to by the thread)

    Pros:

    • "everything" is an object, you don't need separate cases for "real" objects and stack frames
    • this works transparently with value types that contain references
    • this might avoid the register problem completly. if a method makes a "alloc" call the compiler won't be able to prove that the stack frame object hasn't been modified and it will have to reload any registers that have been previously read from stack frame

    Cons:

    • This will very likely disable some compiler optimizations. Usually some of the parameters are passed through registers, this can't happen anymore since the only real parameter will be the pointer to stack frame. Similarly for local variables.

    That is certainly not "illegal" code and the compiler can't guard against it. Now if the original ref to MyClass goes out of scope, then it is no longer reachable and it will be GC'd

    MyClass can't go out of scope, if one of its methods is running then there must be a stack frame for it and that stack frame must contain the "this" pointer for MyClass.

    On a microcontroller it might be more important for the GC to not lock everything up for long periods of times instead of absolute performance.

    Sounds like you want generational GC too. Even more complicated Big Smile.

    What I'm suggesting is improving on this process by stripping the fields out of types that were never referenced during all of the code paths.

    Sure, you could do that. Not sure if it helps with the List<T> case. I looked at the code and it's indeed possible that CultureInfo gets dragged in by an exception (see the Capacity prop). But it's unlikely that you can eliminate that by doing some static code analysis.

  • C++0x (vs2010) question, please tell me what i'm doing wrong

    OK, I understand now. I don't know of a way to remove this overhead, std::function is horrible complex and the compiler has little chance to optimize it.

    It seems to me that if you don't provide the function type in the template argument list (like in the original code or in your code) then the only alternative is to use std::function or something that does something similar: wraps a callable object. And this wrapping is complex because there are different types of callable objects: pointer to function, pointer to member, functors.

  • IL to C++ compiler - Need advice on implementing context switching

    and each of a function's ref type variables and parameters are really a pointer to alocation on this stack like this:

    One thing I don't understand is what are you going to do about value types that contain pointers and are stored on the stack. Did I miss something?

    that might not work because classes that are not reachable will never be called. If those classes are not rooted but they are still performing some sort of operations (maybe in some long running loop or a timer callback), their class variables will not be updated.

    That should never happen, if an object is not reachable then it's garbage and it will be collected. If you pass a GC pointer to native code then you know what you need to do: use "fixed" or GCHandle to prevent the GC from moving/collecting the object.

    So probably I will need to call UpdatePointer on each class while walking the object heap.

    Watch out that moving objects and updating pointers can be extremly tricky. I'm not talking about finding the roots which can be itself a problem, I'm talking about how can you update pointers in an efficient way. One thing is clear: you can't move one object and then call UpdatePointers on all the other objects in the heap, that has quadratic complexity.

    Since evildictait​or mentioned it: have you considered using Boehm GC instead?http://en.wikipedia.org/wiki/Boehm_garbage_collector

    And my C++ code suddenly got hugely bloated with all sorts of seemingly unrelated classes like the CultureInfo

    Hmm, not sure what CultureInfo has to do with List<>. Maybe the Sort method uses it somehow. Since you wrote that code you should be able to modify it to log some information about why a particular type has been included, right? Big Smile If I understand correctly now you're including all the methods of an used type, you may consider excluding methods that are never called.

    so I think it should be possible to make a VS debugging plugin. Has anyone had experience with this, and how difficult would such a project be?

    Absolutely no idea but if you can make all the rest work (compiler, GC etc.) then you should be able to write such a plugin too Smiley

     

  • C++0x (vs2010) question, please tell me what i'm doing wrong

    Best would be if you could make the optimizer inline , etc..

    I don't understand... that's exactly what the compiler did. The code in main is the code from normal_function, 3 calls to the stream insertion operator and nothing else.

  • IL to C++ compiler - Need advice on implementing context switching

    Actually the CLR doesn't make any assumptions like that.

    Actually it does.

    The registers are stored onto the stack

    Actually no. While the kernel may indeed store the registers on the stack when the thread is suspended the only way for an application to get those registers is to call GetThreadContext. Sure, the CONTEXT that you pass to that function can be stored on stack but that's irrelevant here.

    the stack is then inspected for any value that lies within the bounds of the current heap. Any value that falls within an object is marked as live for this round. The root-set computed is therefore a super-set of the "true" root-set, since an integer which happens to hold a value that would also be a valid pointer into the heap might cause a value to live longer than it strictly should

    Nope, this is not what MS's CLR does. What you're describing here sounds like coservative GC, not compacting GC.

    but this doesn't matter since this is much faster than using type information to derive the true root set.

    Actually it matters a lot because it prevents objects from being moved which was one the main questions in this thread. You can't move objects unless you know exactly where pointers are. Or are you suggesting to modify random values in memory that happen to look like pointers?

  • Using TripleDES to encrypt 64 bits, and only 64 bits

    Yay, you were talking about encrypted size and I was talking about the decrypted size. That's because of the padding. If you set PaddingMode to None you'll get 8 bytes if you really need that.

  • Using TripleDES to encrypt 64 bits, and only 64 bits

    Well, I tested again, this time on .NET 2 (previously I used 4). I get 8 bytes in both cases.

    How do you know how many bytes have been returned? Your sample code doesn't show that and in the 3rd cases it's impossible to get more than 8 bytes unless the block size is > 8.

    Btw, in the 3rd case you should check the value returned by Read.

  • Using TripleDES to encrypt 64 bits, and only 64 bits

    The first case doesn't work because you don't call TransformFinalBlock.

    The second case works fine for me, I get 8 bytes, that is 64 bits.

    The third case doesn't work because you flush the write stream but you should close it instead.

  • IL to C++ compiler - Need advice on implementing context switching

    Surely the same issues apply?

    Not really. Since CLR's JIT outputs assembly code it has knowledge about what's in the registers or about points where it is safe to stop the code for GC because there's no pointer in any register. Since you're generating C++ code you don't have this luxury, you're at the mercy of the compiler.