[Vm-dev] Re: [squeak-dev] VM 4.4 build nastinesses - part 1 of probably many

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 12 20:30:59 UTC 2013

On Tue, Feb 12, 2013 at 11:48 AM, tim Rowledge <tim at rowledge.org> wrote:

> OK, reposted her eas Eliot suggested-
> On 11-02-2013, at 8:42 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Tim, ask again on vm-dev.  This is all VM stuff.
> >
> > On Mon, Feb 11, 2013 at 5:53 PM, tim Rowledge <tim at rowledge.org> wrote:
> > Can anyone (Bert?) provide the intended effect and limits of
> ioSetCursorARGB() ? This is a new one on me and the implementations I see
> in the SVN tree mean very little.
> >
> > Can anyone explain why totally inappropriate and highly OS dependant
> code like push/popOutputFile() are in CROSS/sqVirtualMachine.c? The
> definition of stdin/out/err is not a safe one to assume everywhere. Not
> every OS trivially maps a FILE* to a number.

Well, this is really useful for debugging and I was under the impression
that the stdio facilities used here-in are part of the standard C library.
 Personally I'd much rather see the code guarded by an ifdef excluding
RISCOS than I would see three identical copies of the code.  The platform
code is a mess of duplications, and whereeever possible I've been putting
common code in Cross.

BTW, this is a pet peeve of mine.  Not only is there significant
duplication of code, there is egregious difference.  e.g. we have
platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c and
platforms/win32/vm/sqWin32Intel.c, whereas platforms/Mac OS/vm/sqMain.c,
platforms/unix/vm/sqMain.c and platforms/win32/vm/sqMain.c would be far
more rational and easy to search.

So IMO that code is better placed in sqVirtualMachine.c than elsewhere, and
the entire platform hierarchy could do with some serious renaming.

> > It looks like the primitiveFunctionPointer global got changed fro mvoid*
> in 4.0 to void(*)() in 4.4. This is a good thing *if* the matching usages
> are correctly modified; which they aren't. For example in
> primitiveExecuteMethodArgsArray(). On my compiler that is a fatal error -
> as it should be. Is anyone currently fixing that or shall I?

Please do, or send me a pointer.

> Possibly as a side effect primitiveFunctionPointer is no longer in the
> global struct, which may well adversely impact performance.

Two issues here.  a) if it's excluded from the global struct as a a
side-effect it's a bug. b) you need to run a performance comparison to
verify whether the struct works well or not.  For x86 it does not.  Note
that in the Cog branch I went to so,e effort to allow you to select which
variant (struct or flat) at compile time instead of VM generation time.

> Working on the third item since it is if nothing else a good excuse to
> trawl through a lot of code and remind myself of what is where and just how
> much still needs cleaning. I suspect I'll find a lot of it sorted out in
> the stack/cog code anyway but I guess the exercise is good for me.
> I never knew that you could declare an argument in C with "sqInt
> (*thingy[])(void)" ! I hope it actually does what i think it oughta.

yes it does :)


> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Pedaling real fast, but not getting anywhere.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130212/52687e0f/attachment-0001.htm

More information about the Vm-dev mailing list