VM pointers delivered

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

VM pointers delivered

Igor Stasenko
VMMaker-sig.70
Exupery-sig.262

- removed numerous xxxxAddress methods from Interpreter,
ExuperyPlugin, MachineX86.

- added 4 new methods to Interpreter:
exuperyPrimitiveGlobalPtrCount   -- returns number of pointers stored in table

exuperyPrimitiveGlobalPtrByName -- by giving a name of pointer (string
or symbol) returns an array (pointer name proto) , or nil if not found
exuperyPrimitiveGlobalPtrByIndex -- same as above but uses index as parameter
exuperyGetGlobalPtrInfo: -- helper function to generate Array (pointer
name proto)

To see all VM global pointers use Exupery vmGlobalPtrs
 will return dictionary name -> info. where info is array of 4 elements:
- pointer value
- name
- prototype for functions or '<var>' for variables
  a function prototype can be useful to see argument types and names
e.t.c., so, it can be parsed in smalltalk to generate a cdecl callout
to it.
- index in global table ( left for later use , when i add support for
replacing pointer in table :) )

also, note, the function names are stored as smalltalk selectors, not
their corresponding C equivalents.
so, you have names like 'commonVariableInternal:at:cacheIndex:'
instead of 'commonVariableInternalatcacheIndex' in table so its easier
to get to its implementation in Interpreter class.

To see, how globals table generated look at
CCodeGenerator>>emitGlobalTablesOn:methodList:

i'm using struct instead of array, to preserve function names and type
info. so later i can substitute calls like:  foo(bar)  with
VMPointers->foo(bar)
and then be able to replace given function with anything i want.

All tests is passed fine except 3 cases, simply because i don't have
following classes in image:

GraphVizBaseTests
CommandShell
FloatMathPluginTests

i don't think something will change if they will be. :)
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

VM pointers delivered

Bryce Kampjes
sig writes:
 > VMMaker-sig.70
 > Exupery-sig.262
 >
 > To see, how globals table generated look at
 > CCodeGenerator>>emitGlobalTablesOn:methodList:

Unfortunately as it stands it will only work on Windows.

The major problem is the "foo" structure on other platforms that's
used to hold most of the interpreter's variables.

That's why the accessor methods used to call addressOf: rather than
just being "self cCode: '&foo->activeContext'" which is what I
originally did until Andreas tried to do a quick Windows port. He
created addressOf: to provide a platform neutral way of getting the
address of an interpreter structure.

#returnPrefixFromVariable: will return the right form for a variable
on any platform. Unfortunately, you can't dereference foo in another
structure's initialiser.

Andreas created #generateAddressOf:on:indent: to translate
the sender #addressOf: into the appropriate C expression.


I'm not sure about your change to Win32VMMaker>>sourceDirectory.
If I add that to Exupery's VMMaker what will it do to people with
existing Windows build environments?


I like the changes to Exupery itself, it makes the names much more
consistant between the image and the VM but until it will run on
all plaforms I can not accept it.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: VM pointers delivered

Igor Stasenko
On 14/07/07, [hidden email] <[hidden email]> wrote:

> sig writes:
>  > VMMaker-sig.70
>  > Exupery-sig.262
>  >
>  > To see, how globals table generated look at
>  > CCodeGenerator>>emitGlobalTablesOn:methodList:
>
> Unfortunately as it stands it will only work on Windows.
>
> The major problem is the "foo" structure on other platforms that's
> used to hold most of the interpreter's variables.
>
> That's why the accessor methods used to call addressOf: rather than
> just being "self cCode: '&foo->activeContext'" which is what I
> originally did until Andreas tried to do a quick Windows port. He
> created addressOf: to provide a platform neutral way of getting the
> address of an interpreter structure.
>
> #returnPrefixFromVariable: will return the right form for a variable
> on any platform. Unfortunately, you can't dereference foo in another
> structure's initialiser.
>
> Andreas created #generateAddressOf:on:indent: to translate
> the sender #addressOf: into the appropriate C expression.
>
>
> I'm not sure about your change to Win32VMMaker>>sourceDirectory.
> If I add that to Exupery's VMMaker what will it do to people with
> existing Windows build environments?

Ah.. its better to remove this method. i just left it to call super.
Originally (w/o my change) you are unable to change target dir, and i
found this annoying.
And.. i don't know how other people build squeak in windows, but all
my tries to build it from freshly unpacked gnutools and vm sources
failed.
Only after i did some changes in make files i did manage to build
squeak from freshly generated source tree.
Btw, i can provide my makefiles if someone interested.

>
>
> I like the changes to Exupery itself, it makes the names much more
> consistant between the image and the VM but until it will run on
> all plaforms I can not accept it.
>
> Bryce
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: VM pointers delivered

Igor Stasenko
In reply to this post by Bryce Kampjes
Concerning foo struct, as we discussed on IRC:
-first, i'll try to see how fast i can modify Win32 source to use foo struct.
If this is easy task, then i'll do this, and then we'll have to deal
with foo struct for all platforms.
And then i will make use of foo for getting pointers.
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: VM pointers delivered

Igor Stasenko
Ok, i made some changes to make VMPointers work with foo struct.
Since foo always pointing to fum, there's no harm by initializing
pointer to var 'bar' as '&fum.bar', which compiles perfectly :)

Until people deciding using foo struct in windows or not, i left an option there
- if you don't want to use it, simply don't accept
Win32VMMaker>>createCodeGenerator
method. If you do, then don't forget to copy patched platform source
code, which you can find on mantis
http://bugs.squeak.org/view.php?id=6561.
Code works in both cases, so this does not really matter.

Also, i made some changes, to be able generate code with indirect calls.
I think you may be interested to play with.
There is single method  in TSendNode,
and couple #emitFunctionCallFor: , #useIndirectCalls in CCodeGenerator.
If you don't want them - simply do not accept these changes , or
change 'true' to 'false' in

CCodeGenerator>>useIndirectCalls
        ^ true and: [ self isGeneratingPluginCode not]

A cool trick to test, is current code ready for using indirect calls
everywhere in VM/plugins is to change generated function names by
prepending them with '_'.
I really don't care at current stage, how many places in VM/plugins
will require changes, first, i need to finish with compiler
integration for my asm-generator :)
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: VM pointers delivered

Bryce Kampjes
sig writes:
 > Ok, i made some changes to make VMPointers work with foo struct.
 > Since foo always pointing to fum, there's no harm by initializing
 > pointer to var 'bar' as '&fum.bar', which compiles perfectly :)

I've got this building on Linux. I'll try to do a final review
soon.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery