Cog as DLL
Locked
 
Administrator
|
Can Cog, the new VM, be made into a DLL that is callable by external programs? Such a capability will allow Squeak Smalltalk to be used as plugins or addons in many established programs like CAD, spreadsheets, etc.
Aik-Siong Koh |
|
|
Hi Koh,
yes it can. The question is will anybody have the time to do it? It is not part of the plan at Qwaq. I would love to see the Squeak VM and/or Cog evolve into something loadable as a DLL but need to be in some context where I am funded to do the work or can mentor someone else to do the work. This is perhaps a project to suggest for the Google summer of code, although porting to ARM and/or PowerPC would be my first priorities.
Here is a rough list of projects I would like to see done in Cog: - replace the object model with a simpler two-word header design with class indices in the header and with immedate chjaracters (as discussed here or on vm-dev recently)
- port to AMD64/EMT64 with a 64-bit object representation that uses the two-word header format in the new object model and immediate doubles (as I did in 64-bit VW). - port the new JIT to ARM and iPhone
- port the new JIT to PowerPC and PlayStation3 (and older Macs) - replace the existing garbage collector with - a proper scavenging ephemeral collector
- a proper segmented memory model that can add new segments via memory-mapping (mmap/VirtualAlloc) and release these back to the OS, i.e. can grow and shrink, and that can scale to large heaps
- revamp the FFI - replace the FFI/Alien interpreted call-out back-end with one based on an image level ABI compiler that uses Alien-like mechanisms to allocate marshalling code for call-outs and call-backs.
- merge FFI and Alien so that teh Alien model is used for data management - add threaded call-out/call-back support so that the VM can make multiple concurrent (and hence non-blocking) call-outs, and receiver multiple call-backs, even though the core VM is running at most one Smalltalk process concurrently.
- use the threaded facilities to allow the VM to be packaged as a DLL which can receive "send-backs", sends into declared entry-points in the image from a client that loads an image+vm combination as a DLL.
- port Cog beneath other Smalltalks or Smalltalk-like languages On Fri, Mar 13, 2009 at 3:16 PM, askoh <[hidden email]> wrote:
|
[squeak-dev] floats (was: Cog as DLL)
|
|
Eliot Miranda wrote:
> - port to AMD64/EMT64 with a 64-bit object representation that uses > the two-word header format in the new object model and immediate > doubles (as I did in 64-bit VW). One cute idea I saw somewhere was using 64 bit floats for everything, fitting all other objects into the NaN encoding. Even if you select only one of the four kinds of NaNs (postive/negative, signalling/silent) you still have 52 bits to play around with. Would an immediate float representation for 32 bit VMs be of any interest? It seems to me that ...xxxx1 represents SmallIntegers and ...xxxx00 represents oops, so ...xxxx10 would be free to use for floats with 30 bit precision (what Self has). -- Jecel |
|
|
In reply to this post by Eliot Miranda-2
Jecel Assumpcao Jr wrote:
> Eliot Miranda wrote: > >> - port to AMD64/EMT64 with a 64-bit object representation that uses >> the two-word header format in the new object model and immediate >> doubles (as I did in 64-bit VW). > > One cute idea I saw somewhere was using 64 bit floats for everything, > fitting all other objects into the NaN encoding. Even if you select only > one of the four kinds of NaNs (postive/negative, signalling/silent) you > still have 52 bits to play around with. > > Would an immediate float representation for 32 bit VMs be of any > interest? It seems to me that ...xxxx1 represents SmallIntegers and > ..xxxx00 represents oops, so ...xxxx10 would be free to use for floats > with 30 bit precision (what Self has). Yeah, that's cute... but it seems misdirected to me. Are floats that important? I'd actually like to see the compiler emit scaled decimals for literals with decimal points, and have FloatingPointArithmetic be a loadable package for those who know that they really to want floats. Colin |
|
|
In reply to this post by Eliot Miranda-2
Jecel Assumpcao Jr schrieb:
> > Would an immediate float representation for 32 bit VMs be of any > interest? It seems to me that ...xxxx1 represents SmallIntegers and > ...xxxx00 represents oops, so ...xxxx10 would be free to use for floats > with 30 bit precision (what Self has). > That does not work since xxx10 is used as a sentinel value in the garbage collector. I think a better approach is to handle floats specially in a JIT, and keep them unboxed for typical sequences of arithmetic manipulation within methods. Of course, using immediate floats does avoid the object creation and destruction overhead, but you still have some overhead for tagging and untagging, which on modern architectures is still much higher than the actual floating point operation costs. Cheers, Hans-Martin |
|
|
In reply to this post by Colin Putney
On Sat, Mar 14, 2009 at 8:51 PM, Colin Putney <[hidden email]> wrote:
> Yeah, that's cute... but it seems misdirected to me. Are floats that > important? It depends. They are extremely important for scientific computing, they are not nearly as important elsewhere. Most language implementors ignore scientific computing, which is why Fortran still gets used so much. I think it would be reasonable to have an implementation of Smalltalk that focused on making floating point numbers fast and made integer arithmetic slower. For nearly everything that Smalltalk gets used for now, it would be slower than the current apparoch to optimize integer arithmetic. But for real scientific computation, it would be faster. -Ralph |
|
|
In reply to this post by Colin Putney
On 15.03.2009, at 02:51, Colin Putney wrote:
> Are floats that important? For interactive graphics they are, very much, yes, and that is one of the major reasons for Squeak to exist. But even in general, having Float arithmetic is so convenient to developers that it crept into many places that don't even really need it. In an image that is not that important to you, try making Float>>sqrt do "self halt", and then move a window for example. Or take the OLPC hardware designers - they went for the lowest-power chip that had a decent floating point unit (or at least that was a major factor) because there is so much software out there that relies on float support and that does not perform adequately with emulation. - Bert - |
|
|
Quoting "Bert Freudenberg" <[hidden email]>:
> On 15.03.2009, at 02:51, Colin Putney wrote: > >> Are floats that important? > > For interactive graphics they are, very much, yes, and that is one > of the major reasons for Squeak to exist. > > But even in general, having Float arithmetic is so convenient to > developers that it crept into many places that don't even really > need it. In an image that is not that important to you, try making > Float>>sqrt do "self halt", and then move a window for example. > > Or take the OLPC hardware designers - they went for the lowest-power > chip that had a decent floating point unit (or at least that was a > major factor) because there is so much software out there that > relies on float support and that does not perform adequately with > emulation. > > - Bert - > > > > At least some processors used in graphics-based game devices use 'fixed-point arithmetic' instead of floats. These are, in fact, a compromise between integers and floats. Would that be an approach worth looking at? Ivan |
|
|
On 15.03.2009, at 13:20, [hidden email] wrote: > Quoting "Bert Freudenberg" <[hidden email]>: > >> On 15.03.2009, at 02:51, Colin Putney wrote: >> >>> Are floats that important? >> >> For interactive graphics they are, very much, yes, and that is one >> of the major reasons for Squeak to exist. >> >> But even in general, having Float arithmetic is so convenient to >> developers that it crept into many places that don't even really >> need it. In an image that is not that important to you, try making >> Float>>sqrt do "self halt", and then move a window for example. >> >> Or take the OLPC hardware designers - they went for the lowest- >> power chip that had a decent floating point unit (or at least that >> was a major factor) because there is so much software out there >> that relies on float support and that does not perform adequately >> with emulation. >> >> - Bert - >> >> >> >> > > At least some processors used in graphics-based game devices use > 'fixed-point arithmetic' instead of floats. These are, in fact, a > compromise between integers and floats. Would that be an approach > worth looking at? Not for general use. Those game devices do run very specialized software. - Bert - |
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> On 15.03.2009, at 02:51, Colin Putney wrote: > >> Are floats that important? > > For interactive graphics they are, very much, yes, and that is one of > the major reasons for Squeak to exist. > > But even in general, having Float arithmetic is so convenient to > developers that it crept into many places that don't even really need > it. In an image that is not that important to you, try making > Float>>sqrt do "self halt", and then move a window for example. > > Or take the OLPC hardware designers - they went for the lowest-power > chip that had a decent floating point unit (or at least that was a > major factor) because there is so much software out there that relies > on float support and that does not perform adequately with emulation. > > - Bert - > or to work at all, include jpeg image coding and decoding, mp3 audio coding and decoding, video coding and decoding, image scaling (or viewing photos, for example), image processing (for photo enhancing, for example), TrueType fonts, sound synthesis, audio processing, voice synthesis, voice recognition, 3d modeling and rendering (such as Croquet), zoomeable and resolution independent user interfaces, most of the modern effects done by window managers, games, simulations... I'm sure this list could be much larger. DSP chips for embedded devices have specialized in doing float arithmetic with a good and predictable performance long before Intel included it in every desktop. Floats are a great approximation to the "real" thing (i.e. real numbers) a computer can handle, in many cases the best. If the math you're doing includes any transcendental functions, or even division, you should consider using floats seriously. I mean, yes, they are "that" important. Cheers, Juan Vuletich |
|
|
+++ Well said Juan!
Should we purely abandon all these nice features ? Or hide everything under the VM carpet and not let the "impure" floats reach the holy image ? When i read newspeak manifest, that's the negative impression it gives to me... ...I'm clearly not in the niche market they were focusing. IMHO Smalltalk just NEEDS some descent floating point capability to remain the general purpose programming environment it always tried to be. Nicolas 2009/3/15 Juan Vuletich <[hidden email]>
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |