@Igor +1 On Jan 10, 2013 12:14 AM, "Igor Stasenko" <[email protected]> wrote:
> On 9 January 2013 20:58, Eliot Miranda <[email protected]> wrote: > > > > > > Just wrap the assembler up in a string. But this low level shouldn't be > > necessary. If you went the compile-time route then you'd analyse the > call > > according to the platform's ABI and figure out the assembler > automatically. > > This is the architecture I was hoping yopu'd implement. If the > compilation > > step is left until the first call then the signatire becomes > > platform-independent. > > > > Assembler is absolutely necessary, because it is a developer who can > decide to use it, > not me. I just giving an opportunity. > This is a primary objective of NativeBoost project. > NativeBoost includes FFI implementation as integral part of it. > But that doesn't means that i should narrow it down only for this purpose. > > If i want to implement a primitive using brute-force assembler, it is > logical to put it in the source > of corresponding method, not somewhere else. > Also, since this is executable code, and does not requires separate > parser/compiler, > you are free to extensively practice a code-reuse, as in any smalltalk > code you write > (as well as make it platform independent, btw). > And so, users are free to mix assembler with own code, and there is > little or no constraints and canonical forms, to which everyone should > adhere. It is just plain smalltalk. > > > For a clunkier approach see my callback implementation where you build > up a > > library of transformers indexed by signature. The library contains > > different versions for each platform. If you applied this simple idea to > > the above you'd have some pragma somewhere which said "on x86 with > signature > > #( void (void * address, double aDouble) ) output this marshalling code: > > #(pop: EDX "load an...") etc. And then the call site would just supply > the > > signature. You'd get to share the marshalling code between functions > having > > the same signatures and you'd have a level of platform-independence. > > > > Wait.. Let us separate concerns. Platform-independence is orthogonal > to use (or not) use of pragmas in code. > > I do not see why i need to focus on platform independence right here right > now. > Does our beloved VM runs anywhere else than on 32-bit x86 CPUs? > Once there will be other options, trust me, i will be first who will > concentrate on making > things properly separated. > But when it is not , why i do even need to think/do something about it? > x64 using completely different call convention(s), not saying that > object format will > require some changes, and as result VM interface(s) as well.. > So, why i should constrain myself and introduce some "platform independece" > when i have no real thing at hand, so i don't even have a clue whether > my "platform-independent" > solution will will fit well with future VM/platform or not? > > Aside of it, right now, you can debug the code generation and see > everything from starting point > up to the end, using debugger just by stepping into method which uses NB > call. > You can see what happens, and see how your function signature turned > into real bytes which then fed to CPU. So, users can LEARN and improve > it. > Now if you split things , or even worse, move all logic at compile > time, you will make things opaque enough for debugging it and > understanding how it works. > Yes, this is good, if intent is to prevent a "regular" developer to > even think that he can directly use assembler. But my intent is > actually straightly opposite. > > My intent is to expose users to it. > I am perfectly fine with those who prefer to keep playing with plastic > toys without risk of hurting themselves. > But plastic world(s) has own limits, and so, if you want to reach outside, > then there is no magic, you have to stop playing in sandbox with > plastic toys, but instead grow up and take some risk and > responsibility. > And so, my philosophy (and NB as well) is to help people breaking out > and combine best of two worlds. > > Because, at the end, which code is more secure/safe: > - a well debugged and tested C code > - or a well debugged and tested smalltalk code > ? > > > -- > Best regards, > Igor Stasenko. > >
