[Mono-dev] XScale?, Mono-devel-list Digest, Vol 18, Issue 62
cody at lodrige.com
cody at lodrige.com
Thu Oct 26 01:53:21 EDT 2006
Hello all,
I know mono will run on OMAPs (nokia 770), and I managed to get the same binary to run a Cirrus Logic EP9302.
What is required to get mono to run on XScale. I have an application in mind that uses a PXA255, and I would love to use C#...
Thanks!
J.Cody
>-----Original Message-----
>From: mono-devel-list-request at lists.ximian.com [mailto:mono-devel-list-request at lists.ximian.com]
>Sent: Thursday, October 26, 2006 12:11 AM
>To: mono-devel-list at lists.ximian.com
>Subject: Mono-devel-list Digest, Vol 18, Issue 62
>
>Send Mono-devel-list mailing list submissions to
> mono-devel-list at lists.ximian.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>or, via email, send a message with subject or body 'help' to
> mono-devel-list-request at lists.ximian.com
>
>You can reach the person managing the list at
> mono-devel-list-owner at lists.ximian.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Mono-devel-list digest..."
>
>
>Today's Topics:
>
> 1. Re: Managed DirectX (Brian Crowell)
> 2. Re: Managed DirectX (Stefan D?singer)
> 3. Re: Managed DirectX (Brian Crowell)
> 4. [PATCH] Optimize Encoding.GetByteCount (Ben Maurer)
> 5. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno)
> 6. Re: [PATCH] Optimize Encoding.GetByteCount (Aaron Bockover)
> 7. Re: [PATCH] Optimize Encoding.GetByteCount (Alan McGovern)
> 8. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno)
> 9. Re: Managed DirectX (Miguel de Icaza)
> 10. [PATCH] OS X MACHINE_THREAD_STATE patch for newer 10.4u SDK
> (Allan Hsu)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 25 Oct 2006 13:31:07 -0500
>From: Brian Crowell <mono-devel at fluggo.com>
>Subject: Re: [Mono-dev] Managed DirectX
>To: Michael Schurter <michael at synthesyssolutions.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <453FAD6B.5020509 at fluggo.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Michael Schurter wrote:
>> Careful what you do with ILDASM Brian, at least if you plan on
>> contributing code to the mono project:
>
>Yes, I know. I mostly just wanted to figure out how they made calls; everything else in my own managed implementation is written from scratch using documentation. Better yet, I throw more useful exceptions.
>
>Anyhow, does anyone know of a good way to step around the hand-coded interop problem without using Managed C++ or C++/CLI?
>
>--Brian
>
>
>------------------------------
>
>Message: 2
>Date: Wed, 25 Oct 2006 20:49:29 +0200
>From: Stefan D?singer <stefandoesinger at gmx.at>
>Subject: Re: [Mono-dev] Managed DirectX
>To: Brian Crowell <mono-devel at fluggo.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <200610252049.35526.stefandoesinger at gmx.at>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Am Mittwoch 25 Oktober 2006 19:02 schrieben Sie:
>> A practical example of building a wrapper by hand would be most helpful.
>> Late binding is not an option, and I haven't ever found interface
>> definition files for DirectX9.
>As far as I know idl files for dx9 do not exist, only the d3d9.h, d3d9types.h
>and d3d9caps.h(simmilar for other dx parts), but with dx10 ms started using
>idl files.
>
>So from the other replies it sounds like you can use wine for dx, but mono
>needs some preparation work first. If you need any help just contact me or
>the wine-devel list :-)
>
>Stefan
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: not available
>Type: application/pgp-signature
>Size: 189 bytes
>Desc: not available
>Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061025/f9253082/attachment-0001.bin
>
>------------------------------
>
>Message: 3
>Date: Wed, 25 Oct 2006 14:08:14 -0500
>From: Brian Crowell <mono-devel at fluggo.com>
>Subject: Re: [Mono-dev] Managed DirectX
>To: Stefan D?singer <stefandoesinger at gmx.at>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <453FB61E.6040705 at fluggo.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Stefan D?singer wrote:
>> So from the other replies it sounds like you can use wine for dx, but mono
>> needs some preparation work first. If you need any help just contact me or
>> the wine-devel list :-)
>
>Well, one option is to use a library written in C++/CLI, compile it with Microsoft's C++ compiler, and then use the resulting library with Mono. That should work. There's just no equivalent all-Mono method.
>
>Tell you what. Sometime this week I'll look to release what I have done regarding XNA. It won't be exactly what you want-- in particular, my library depends on a common primitives library-- but it could be a good starting point for a Managed DirectX 9 implementation.
>
>--Brian
>
>
>------------------------------
>
>Message: 4
>Date: Wed, 25 Oct 2006 16:51:57 -0400 (EDT)
>From: "Ben Maurer" <bmaurer at ximian.com>
>Subject: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
>To: mono-devel-list at lists.ximian.com
>Message-ID:
> <37993.130.57.170.100.1161809517.squirrel at webmail.ximian.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hey guys,
>
>On the 2.0 profile, Encoding uses the char*/byte* version of encoding
>methods to avoid allocating memory. One code path missed this
>optimization, I've attached a fix.
>
>This code path ends up being used in Banshee quite a bit on their tree
>view (basically, every time the model is queried, this method gets called
>in passing String objects to char*).
>
>A few things to think about:
>
>- It might pay to do something on the 1.0 profile as well.
>- Paolo, can you comment on how this kind of change works with the moving gc?
>
>-b
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: enc.patch
>Type: text/x-patch
>Size: 712 bytes
>Desc: not available
>Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061025/8d07183e/attachment-0001.bin
>
>------------------------------
>
>Message: 5
>Date: Thu, 26 Oct 2006 06:06:28 +0900
>From: Atsushi Eno <atsushi at ximian.com>
>Subject: Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
>To: Ben Maurer <bmaurer at ximian.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <453FD1D4.6080500 at ximian.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Ben Maurer wrote:
>> Hey guys,
>>
>> On the 2.0 profile, Encoding uses the char*/byte* version of encoding
>> methods to avoid allocating memory. One code path missed this
>> optimization, I've attached a fix.
>
>nice :-) Comment for patch below.
>
>> - It might pay to do something on the 1.0 profile as well.
>> - Paolo, can you comment on how this kind of change works with the moving gc?
>
>To my understanding, fixed pointers do not participate GC target. And
>- locally-allocated array anyways lives until its conversion finishes
> (and probably immediately disposed depending on the JIT optimization)
>- Usually this conversion do not take long time
>So I guess fixed pointer would work better than possibly being moved
>from nursery area.
>
>
>> + if (s == null)
>> throw new ArgumentNullException ("s");
>> +#if NET_2_0
>> + unsafe {
>> + fixed (char* cptr = s) {
>> + return GetByteCount (cptr, s.Length);
>> + }
>> }
>> +#else
>> + char[] chars = s.ToCharArray ();
>> + return GetByteCount (chars, 0, chars.Length);
>> +#endif
>
>Before fixing the pointer you have to make sure that s is non-zero length.
>
>Atsushi Eno
>
>
>------------------------------
>
>Message: 6
>Date: Wed, 25 Oct 2006 17:19:53 -0400
>From: Aaron Bockover <abockover at novell.com>
>Subject: Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
>To: Ben Maurer <bmaurer at ximian.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <1161811193.4788.14.camel at linux-0790.site>
>Content-Type: text/plain
>
>Thanks Ben!
>--Aaron
>
>
>On Wed, 2006-10-25 at 16:51 -0400, Ben Maurer wrote:
>> Hey guys,
>>
>> On the 2.0 profile, Encoding uses the char*/byte* version of encoding
>> methods to avoid allocating memory. One code path missed this
>> optimization, I've attached a fix.
>>
>> This code path ends up being used in Banshee quite a bit on their tree
>> view (basically, every time the model is queried, this method gets called
>> in passing String objects to char*).
>>
>> A few things to think about:
>>
>> - It might pay to do something on the 1.0 profile as well.
>> - Paolo, can you comment on how this kind of change works with the moving gc?
>>
>> -b
>> _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>------------------------------
>
>Message: 7
>Date: Wed, 25 Oct 2006 22:53:51 +0100
>From: "Alan McGovern" <alan.mcgovern at gmail.com>
>Subject: Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
>To: mono-devel-list at lists.ximian.com
>Message-ID:
> <117799f00610251453w3aa6c5abr127bd697ab55627b at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>> To my understanding, fixed pointers do not participate GC target. And
>> - locally-allocated array anyways lives until its conversion finishes
>> (and probably immediately disposed depending on the JIT optimization)
>> - Usually this conversion do not take long time
>> So I guess fixed pointer would work better than possibly being moved
>> from nursery area.
>
>
>It's better to not allocate a new array if it can be avoided. From my own
>code i found that in one of my intensively used methods i allocated a
>100byte array each time the method was called. By moving that variable
>outside the method and just reinitialising it each time i used it (with
>appropriate locking) memory usage reduced by a large %. Don't rely on the GC
>to tidy up your mess if you can avoid creating it in the first place :p
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061025/be451a55/attachment-0001.html
>
>------------------------------
>
>Message: 8
>Date: Thu, 26 Oct 2006 07:02:02 +0900
>From: Atsushi Eno <atsushi at ximian.com>
>Subject: Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
>To: Alan McGovern <alan.mcgovern at gmail.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <453FDEDA.70306 at ximian.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Hi,
>
>Well, the point of the Ben's question is, compacting GC is likely to
>store array in nursery area (likely, since it could be regarded too
>big to store in nursery area), so nursery allocation and releasing
>might become faster than fixing string pointer which might slowdown GC.
>
>(That's why BenM asked Paolo, as only he would know the best answer ;-)
>
>Atsushi Eno
>
>Alan McGovern wrote:
>>> To my understanding, fixed pointers do not participate GC target. And
>>> - locally-allocated array anyways lives until its conversion finishes
>>> (and probably immediately disposed depending on the JIT optimization)
>>> - Usually this conversion do not take long time
>>> So I guess fixed pointer would work better than possibly being moved
>>> from nursery area.
>>
>>
>> It's better to not allocate a new array if it can be avoided. From my own
>> code i found that in one of my intensively used methods i allocated a
>> 100byte array each time the method was called. By moving that variable
>> outside the method and just reinitialising it each time i used it (with
>> appropriate locking) memory usage reduced by a large %. Don't rely on
>> the GC
>> to tidy up your mess if you can avoid creating it in the first place :p
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>------------------------------
>
>Message: 9
>Date: Wed, 25 Oct 2006 20:53:04 -0400
>From: Miguel de Icaza <miguel at ximian.com>
>Subject: Re: [Mono-dev] Managed DirectX
>To: Stefan D?singer <stefandoesinger at gmx.at>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <1161823984.5109.26.camel at erandi.dom>
>Content-Type: text/plain
>
>Hello,
>
>> I am one of the programmers of the Wine Direct3D implementation, and I
>> wondered if there are any plans to implement Managed DirectX in Mono, and if
>> it is possible to share efforts between wine and mono?
>
>This would be fantastic.
>
>> This is basically what the wine direct3d code looks like: We have 3 libraries
>> for the various dx versions, ddraw.dll, d3d8.dll and d3d9.dll. Plans are
>> going on for a d3d10.dll. Those libraries offer a binary and source
>> compatible interface to Microsoft's Direct3D user mode interface. We do not
>> implement the kernel-side DDI or gdientry/ddentry interface and we do not
>> plan to do that.
>
>Does the library depend on the rest of Wine to run?
>
>Am curious if it is possible to write a C program that can just call
>into these libraries directly?
>
>I mention this because Mono would be accessing the libraries by
>dlopening them, looking up the addresses of methods with dlsym and
>calling them.
>
>And the question is whether this means that we need to run side-by-side
>with the Wine runtime, as that is currently not possible with Mono.
>
>Miguel.
>
>
>------------------------------
>
>Message: 10
>Date: Wed, 25 Oct 2006 20:22:32 -0700
>From: allan at counterpop.net (Allan Hsu)
>Subject: [Mono-dev] [PATCH] OS X MACHINE_THREAD_STATE patch for newer
> 10.4u SDK
>To: mono-devel-list at lists.ximian.com
>Message-ID: <20061026032232.GA14592 at daybreaker.counterpop.net>
>Content-Type: text/plain; charset="us-ascii"
>
>This patch fixes problems with building mono for i386 using the new
>10.4u SDK that ships with Xcode 2.4. Current SVN builds for i386 under
>the new SDK, but does not run properly due to changes in
>MACHINE_THREAD_STATE. It looks like the breakage in source compatibility
>is intentional on Apple's part and future headers will be similarly
>broken.
>
>I will be submitting the same patch to libgc upstream.
>
> -Allan
>--
>Allan Hsu <allan at counterpop dot net>
>1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779
>-------------- next part --------------
>Index: libgc/darwin_stop_world.c
>===================================================================
>--- libgc/darwin_stop_world.c (revision 66738)
>+++ libgc/darwin_stop_world.c (working copy)
>@@ -75,12 +75,14 @@
> ptr_t lo, hi;
> #if defined(POWERPC)
> ppc_thread_state_t state;
>+ mach_msg_type_number_t thread_state_count = PPC_THREAD_STATE_COUNT;
> #elif defined(I386)
> i386_thread_state_t state;
>+ mach_msg_type_number_t thread_state_count = i386_THREAD_STATE_COUNT;
> #else
> # error FIXME for non-x86 || ppc architectures
>+ mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT;
> #endif
>- mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT;
>
> me = pthread_self();
> if (!GC_thr_initialized) GC_thr_init();
>@@ -94,7 +96,7 @@
> /* Get the thread state (registers, etc) */
> r = thread_get_state(
> p->stop_info.mach_thread,
>- MACHINE_THREAD_STATE,
>+ GC_MACH_THREAD_STATE_FLAVOR,
> (natural_t*)&state,
> &thread_state_count);
> if(r != KERN_SUCCESS) ABORT("thread_get_state failed");
>@@ -193,7 +195,7 @@
> ppc_thread_state64_t info;
> # endif
> mach_msg_type_number_t outCount = THREAD_STATE_MAX;
>- r = thread_get_state(thread, MACHINE_THREAD_STATE,
>+ r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR,
> (natural_t *)&info, &outCount);
> if(r != KERN_SUCCESS) continue;
>
>@@ -236,7 +238,7 @@
> WARN("This is completely untested and likely will not work\n", 0);
> i386_thread_state_t info;
> mach_msg_type_number_t outCount = THREAD_STATE_MAX;
>- r = thread_get_state(thread, MACHINE_THREAD_STATE,
>+ r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR,
> (natural_t *)&info, &outCount);
> if(r != KERN_SUCCESS) continue;
>
>Index: libgc/include/private/gc_priv.h
>===================================================================
>--- libgc/include/private/gc_priv.h (revision 66738)
>+++ libgc/include/private/gc_priv.h (working copy)
>@@ -366,6 +366,16 @@
> # define BZERO(x,n) bzero((char *)(x),(int)(n))
> # endif
>
>+#if defined(DARWIN)
>+# if defined(POWERPC)
>+# define GC_MACH_THREAD_STATE_FLAVOR PPC_THREAD_STATE
>+# elif defined(I386)
>+# define GC_MACH_THREAD_STATE_FLAVOR i386_THREAD_STATE
>+# else
>+# define GC_MACH_THREAD_STATE_FLAVOR MACHINE_THREAD_STATE
>+# endif
>+#endif
>+
> /* Delay any interrupts or signals that may abort this thread. Data */
> /* structures are in a consistent state outside this pair of calls. */
> /* ANSI C allows both to be empty (though the standard isn't very */
>Index: libgc/os_dep.c
>===================================================================
>--- libgc/os_dep.c (revision 66738)
>+++ libgc/os_dep.c (working copy)
>@@ -3702,7 +3702,7 @@
> mask,
> GC_ports.exception,
> EXCEPTION_DEFAULT,
>- MACHINE_THREAD_STATE
>+ GC_MACH_THREAD_STATE_FLAVOR
> );
> if(r != KERN_SUCCESS) ABORT("task_set_exception_ports failed");
>
>
>------------------------------
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>End of Mono-devel-list Digest, Vol 18, Issue 62
>***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061026/610c113e/attachment.html
More information about the Mono-devel-list
mailing list