[M3devel] pixmap problem

Mon May 5 16:59:27 CEST 2008

Jay:

The TestPixmap.zip is attached.

I will attempt to update all my sources and try again.

Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.

The pixmap problem does not occur on 4.1.

Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.

(It's not really a config file issue, don't blame the general confusion
people have with them.)

I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..

If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.

Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

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
targets, 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 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.

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
results 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
imported.
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
.dll, 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
Foo.
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 imported.
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. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080505/9ee50c37/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestPixmap.zip
Type: application/x-zip-compressed
Size: 4870 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080505/9ee50c37/attachment-0002.bin>