[M3devel] pixmap problem

[Mika Nystrom]

It works great on NT386GNU, PM3/Klagenfurt, as well, without the
build_standalone.
 
    Mika

"Daniel Alejandro Benavides D." writes:
>--0-1095273535-1200761640=:77597
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>Hi:
>The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.
>
>Thanks
>
>
>Jay <jayk123 at hotmail.com> wrote:    .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  I can repro
> the two different behaviors on XP.
> I was going to try on PPC_DARWIN but I guess Tony's info suffices.
>  
> I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
>  
> Debugging here is a big humungous pain.
> NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it
> is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta
>rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm
> not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info
>, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th
>ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length.
> At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with
> no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
>  
> You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
> And bundles look pretty simple, a bundle is just a generated source file with a constant in it.
> Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal 
>something.
>  
> The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical
> stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul
>ts from some common pixmap mismanagement we could look for?
>  
> I have to say this is very surprising.
>  
> I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports 
>functions, right?
> On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo
>rted.
> For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
>  
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
> The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d
>ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
>  
> That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
>  
> pointer to msvcrt!fopen
> pointer to msvcrt!fclose
> null
> pointer to kernel32!Sleep
>  
> But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent.
>  
> So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo
>o.
> But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.
> That doesn't work for data though. There's no ability to intervenve like that.
> So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe
>d.
> Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.
> And for this reason, I HOPE Modula-3 never imports/exports data.
>  
> Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
> However that would suck perf in order to make an uncommon case work.
> I hope Modula-3 doesn't do that either. :)
> Though I guess since this global data in question...maybe it is rare???
>  
> Later,
>  - Jay
>
>
>  
>---------------------------------
> 
> > From: hosking at cs.purdue.edu
>> Date: Sat, 19 Jan 2008 03:09:47 -0500
>> To: rcoleburn at scires.com
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] pixmap problem
>> 
>> Looks fine to me on I386_DARWIN.
>> 
>> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
>> 
>> > <TestPixmap.zip>
>> 
>
>
>
>---------------------------------
>Need to know the score, the latest news, or you need your Hotmail®-get your "fix" Check it out.
>
>       
>---------------------------------
>
>Web Revelación Yahoo! 2007:
> Premio Favorita del Público - ¡Vota tu preferida!
>--0-1095273535-1200761640=:77597
>Content-Type: text/html; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>Hi:<br>The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.<br><br>Thanks<br><br><br><b><i>Jay &l
>t;jayk123 at hotmail.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-lef
>t: 5px;">   <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> I can repro the two
> different behaviors on XP.<br> I was going to try on PPC_DARWIN but I guess Tony's info suffices.<br>  <br> I tried rolling hand.c back to
> before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.<br>  <br> Debugging here is a big humungous&nb
>sp;pain.<br> NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs.
>..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this
> reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui
>ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if 
>it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers 
>to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it
>, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to 
>completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.<br>  <br> You wri
>te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)<br> And bundles look pretty
> simple, a bundle is just a generated source file with a constant in it.<br> Maybe newline problems? That wouldn't make sense. I just downl
>oaded some program that might let me separately view the ppm, maybe it'll reveal something.<br>  <br> The bad behavior has like regularly s
>paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte
>rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme
>nt we could look for?<br>  <br> I have to say this is very surprising.<br>  <br> I always wondered, and now I pretty much assume -- Mo
>dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?<br> On Windows, functions have an op
>tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.<br> For
> functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.<br>  <br
>> That is, given a symbol Foo, there is a symbol __imp__<font face="">Foo</font> that is a pointer to the actual foo in another .dll/.so.<br> Th
>e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a 
>.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.<br>  <br> That is, if cal
>l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:<br>  <br> pointer to msvcrt!fopen<br> pointer to msvcrt
>!fclose<br> null<br> pointer to kernel32!Sleep<br>  <br> But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent
>.<br>  <br> So, going back, my point/question is that, if the compiler knows the function is imported, it can call
> through __imp__Foo instead of calling Foo.<br> But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t
>hrough __imp__Foo.<br> That doesn't work for data though. There's no ability to intervenve like that.<br> So for imported data, the compiler mus
>t generated a read and dereference of the pointer __imp__<font face="">Foo for accesses to Foo, if Foo is to be imported.</font><br> Data import
>s may be faster when appropriate, but for this reason, I'd say they aren't worth it.<br> And for this reason, I HOPE Modula-3 never imports/expo
>rts data.<br>  <br> Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.<br> However that 
>would suck perf in order to make an uncommon case work.<br> I hope Modula-3 doesn't do that either. :)<br> Though I guess since this global data
> in question...maybe it is rare???<br>  <br> Later,<br>  - Jay<br><br><br>  <hr id="stopSpelling"> <br> > From:
> hosking at cs.purdue.edu<br>> Date: Sat, 19 Jan 2008 03:09:47 -0500<br>> To: rcoleburn at scires.com<br>> CC: m3devel at elegosoft.com<br>> 
>Subject: Re: [M3devel] pixmap problem<br>> <br>> Looks fine to me on I386_DARWIN.<br>> <br>> On Jan 19, 2008, at 12:31 AM, Randy Col
>eburn wrote:<br>> <br>> > <TestPixmap.zip><br>> <br><br><br><hr>Need to know the score, the latest news, or you need your Hotm
>ail®-get your "fix" <a href="http://www.msnmobilefix.com/Default.aspx" target="_new">Check it out.</a></blockquote><br><p> 
>
>
>      <hr size=1><br><font face="Verdana" size="-2">Web Revelación Yahoo! 2007:<br> Premio Favorita del Público - <a href="http://es.promotions.ya
>hoo.com/revelacion2007/favoritos/">¡Vota tu preferida!</a></font>
>--0-1095273535-1200761640=:77597--