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

[Igor Stasenko]

On 12 February 2013 22:30, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> 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.

+1
it was always occurred to me, why those files need to have different
names while lying in separate directories.

>
>> >
>> > 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 :)
>
>
> And WELCOME BACK!!!!
>
>>
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- Pedaling real fast, but not getting anywhere.
>>
>>
>
>
>
> --
> best,
> Eliot
>



-- 
Best regards,
Igor Stasenko.