Where are we at?

Jan 15, 2012 at 4:13 AM

Hey guys, not trying to be a pest, but I was wondering were we are at for filesystem support? I know Kudzu has some code in breakpointos but I couldn't ever get it to run, it just said memory block reached or something. Anyway just wondering. Thanks - Matt

Jan 15, 2012 at 4:56 AM
civilwarrock wrote:

Hey guys, not trying to be a pest, but I was wondering were we are at for filesystem support? I know Kudzu has some code in breakpointos but I couldn't ever get it to run, it just said memory block reached or something. Anyway just wondering. Thanks - Matt

Last I heard, they halted *full* file system supported (for the moment). Although they had implemented partial FAT and EXT2 support (you mentioned something about trying some assorted code so I guess that have *something*), they had to stop because of bugs in the compiler and they started on an assembly level debugger -- but of course that was a month or so ago... :P

Jan 15, 2012 at 5:00 AM
blackfireize wrote:
civilwarrock wrote:

Hey guys, not trying to be a pest, but I was wondering were we are at for filesystem support? I know Kudzu has some code in breakpointos but I couldn't ever get it to run, it just said memory block reached or something. Anyway just wondering. Thanks - Matt

Last I heard, they halted *full* file system supported (for the moment). Although they had implemented partial FAT and EXT2 support (you mentioned something about trying some assorted code so I guess that have *something*), they had to stop because of bugs in the compiler and they started on an assembly level debugger -- but of course that was a month or so ago... :P

Lol, yeah hopefully a person working on filesystem support can give us a answer. :p Thanks -  Matt

Coordinator
Jan 15, 2012 at 3:59 PM
> *something*), they had to stop because of bugs in the compiler and they
> started on an assembly level debugger -- but of course that was a month
> or so ago... :P

We are still working on debuggers to fix some of the bugs. A few bugs
(uint64 and others) are fixed but there is now a blocking field init bug.
Coordinator
Jan 15, 2012 at 3:59 PM
> couldn't ever get it to run, it just said memory block reached or
> something. Anyway just wondering. Thanks - Matt

Yes, that error is a result of a compiler bug we are working on.
Jan 15, 2012 at 7:34 PM
kudzu wrote:
> couldn't ever get it to run, it just said memory block reached or
> something. Anyway just wondering. Thanks - Matt

Yes, that error is a result of a compiler bug we are working on.

Oh ok, makes sense. I bet those little bugs are annoying. Thanks - Matt

Coordinator
Jan 16, 2012 at 8:15 AM
We think we have FAT read/write implemented, but are hit by a serious compiler bug (porobably a 1-2 liner somewhere in the compiler, but go find it.. :( )
To ease the pain of solving it we're spending time on the debugger. time has tought us that spending time on the compiler in these cases pays out quadruple.....


On Sun, Jan 15, 2012 at 8:34 PM, civilwarrock <notifications@codeplex.com> wrote:

From: civilwarrock

kudzu wrote:
> couldn't ever get it to run, it just said memory block reached or
> something. Anyway just wondering. Thanks - Matt

Yes, that error is a result of a compiler bug we are working on.

Oh ok, makes sense. I bet those little bugs are annoying. Thanks - Matt

Read the full discussion online.

To add a post to this discussion, reply to this email (Cosmos@discussions.codeplex.com)

To start a new discussion for this project, email Cosmos@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Jan 16, 2012 at 1:29 PM
> To ease the pain of solving it we're spending time on the debugger. time
> has tought us that spending time on the compiler in these cases pays out
> quadruple.....

Far more than quadruple.. its exponential.
Developer
Jan 17, 2012 at 1:56 PM

As proved by the speed at which I was able to give kuzu a very interesting fact about the field init bug, it sets the correct value initially (verified via the debugger(which now supports fields, huzzah!) ), however, somewhere that value is getting borked. It may very well be in the casting code, as the pointers look like they're changing after the cast, which, if I understand the way we layout fields, shouldn't be happening.
Here's the way I understand the layout of fields:

((Type Information)-(Base Type's Fields)-(This Type's Fields))

Thus, to cast to a different type, we still keep the same pointer to that object, just change the type we track it as in IL2CPU (no change is needed to the actual object itself.)


As always, please correct me if I'm wrong.

Coordinator
Jan 17, 2012 at 2:01 PM
On 1/17/2012 9:57 AM, blah38621 wrote:
> As proved by the speed at which I was able to give kuzu a very
> interesting fact about the field init bug, it sets the correct value
> initially (verified via the debugger(which now supports fields, huzzah!)
> ), however, somewhere that value is getting borked. It may very well be
> in the casting code, as the pointers look like they're changing after
> the cast, which, if I understand the way we layout fields, shouldn't be
> happening.
> Here's the way I understand the layout of fields:
>
> ((Type Information)-(Base Type's Fields)-(This Type's Fields))
>
> Thus, to cast to a different type, we still keep the same pointer to
> that object, just change the type we track it as in IL2CPU (no change is
> needed to the actual object itself.)

We've tracked it down to the reading... Matthijs thinks callvirt might
have some issues.
Coordinator
Jan 17, 2012 at 2:05 PM
it's not callvrt (at least not because of the reason i thought)...


On Tue, Jan 17, 2012 at 3:01 PM, kudzu <notifications@codeplex.com> wrote:

From: kudzu

On 1/17/2012 9:57 AM, blah38621 wrote:
> As proved by the speed at which I was able to give kuzu a very
> interesting fact about the field init bug, it sets the correct value
> initially (verified via the debugger(which now supports fields, huzzah!)
> ), however, somewhere that value is getting borked. It may very well be
> in the casting code, as the pointers look like they're changing after
> the cast, which, if I understand the way we layout fields, shouldn't be
> happening.
> Here's the way I understand the layout of fields:
>
> ((Type Information)-(Base Type's Fields)-(This Type's Fields))
>
> Thus, to cast to a different type, we still keep the same pointer to
> that object, just change the type we track it as in IL2CPU (no change is
> needed to the actual object itself.)

We've tracked it down to the reading... Matthijs thinks callvirt might
have some issues.

Read the full discussion online.

To add a post to this discussion, reply to this email (Cosmos@discussions.codeplex.com)

To start a new discussion for this project, email Cosmos@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Jan 17, 2012 at 2:10 PM
Can someone port the code of the get_BlockSize method?


On Tue, Jan 17, 2012 at 3:05 PM, Matthijs ter Woord <matthijsterwoord@gmail.com> wrote:
it's not callvrt (at least not because of the reason i thought)...


On Tue, Jan 17, 2012 at 3:01 PM, kudzu <notifications@codeplex.com> wrote:

From: kudzu

On 1/17/2012 9:57 AM, blah38621 wrote:
> As proved by the speed at which I was able to give kuzu a very
> interesting fact about the field init bug, it sets the correct value
> initially (verified via the debugger(which now supports fields, huzzah!)
> ), however, somewhere that value is getting borked. It may very well be
> in the casting code, as the pointers look like they're changing after
> the cast, which, if I understand the way we layout fields, shouldn't be
> happening.
> Here's the way I understand the layout of fields:
>
> ((Type Information)-(Base Type's Fields)-(This Type's Fields))
>
> Thus, to cast to a different type, we still keep the same pointer to
> that object, just change the type we track it as in IL2CPU (no change is
> needed to the actual object itself.)

We've tracked it down to the reading... Matthijs thinks callvirt might
have some issues.

Read the full discussion online.

To add a post to this discussion, reply to this email (Cosmos@discussions.codeplex.com)

To start a new discussion for this project, email Cosmos@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com



Developer
Jan 17, 2012 at 2:16 PM

not sure, but there may still be an issue with callvirt, namely this:

if (!aTargetMethod.IsStatic) 
{
    //xThisOffset += Align(SizeOfType(aTargetMethod.DeclaringType), 4);
    Assembler.Stack.Pop();
}


If we're popping from the stack shouldn't we be adding the proper offset?

Coordinator
Jan 17, 2012 at 2:20 PM
it's the analysis stack, which goes ok.
can you post me the .asm code from the .get_BlockSize method?

On Tue, Jan 17, 2012 at 3:16 PM, blah38621 <notifications@codeplex.com> wrote:

From: blah38621

not sure, but there may still be an issue with callvirt, namely this:

if (!aTargetMethod.IsStatic) 
{
    //xThisOffset += Align(SizeOfType(aTargetMethod.DeclaringType), 4);
    Assembler.Stack.Pop();
}


If we're popping from the stack shouldn't we be adding the proper offset?

Read the full discussion online.

To add a post to this discussion, reply to this email (Cosmos@discussions.codeplex.com)

To start a new discussion for this project, email Cosmos@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Jan 17, 2012 at 2:24 PM

ah, nvm, just took notice of the name of the variable it was adding to. (perhaps we should remove that commented out line completely, to prevent confusion in the future?) Also, I'm not near a computer with Cosmos on it atm :(

Developer
Jan 17, 2012 at 2:36 PM

I can upload the .asm file if you can find what he's asking for?

Coordinator
Jan 17, 2012 at 2:38 PM
please just post an excerpt to a site like nopaste..


On Tue, Jan 17, 2012 at 3:36 PM, geramy <notifications@codeplex.com> wrote:

From: geramy

I can upload the .asm file if you can find what he's asking for?

Read the full discussion online.

To add a post to this discussion, reply to this email (Cosmos@discussions.codeplex.com)

To start a new discussion for this project, email Cosmos@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Jan 17, 2012 at 2:38 PM

Asm data right here

http://pastebin.com/j7rpYiFS