SPECIAL[T]
|
|
helmut.brandl
|
It seems that the implementation of SPECIAL in FreeELKS has a strong
impact on the underlying runtime system. It has a query "base_address" which is not builtin and returns the address of the special object. This requires from the runtime that the first object in the array starts aligned with the adress of the special object. So administrative information like the capacity and the element size cannot be stored within the object. It has a queries count and element_size which are builtin. But according to the above restriction, the runtime cannot store that information in the object. It has to store it somewhere outside the object. Probably Eiffelstudio and gec store that information in the garbage collection tag. Is it the intention of FreeELKS to restrict the implementation freedom of other compilers in that way (e.g. I want to do garbage collection with only 2 machine words of overhead)? With tecomp I want to implement a very runtime efficient and compact form of garbage collection. However I have not yet found a way to reconcile that garbage collector with the interference from FreeELKS. Regards Helmut The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp Documentation: http://tecomp.sourceforge.net ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
||||||||||||||||
Eric Bezault-3
|
Helmut Brandl wrote:
> It seems that the implementation of SPECIAL in FreeELKS has a strong > impact on the underlying runtime system. > > It has a query "base_address" which is not builtin and returns the > address of the special object. This requires from the runtime that the > first object in the array starts aligned with the adress of the special > object. So administrative information like the capacity and the element > size cannot be stored within the object. > > It has a queries count and element_size which are builtin. But according > to the above restriction, the runtime cannot store that information in > the object. It has to store it somewhere outside the object. Probably > Eiffelstudio and gec store that information in the garbage collection > tag. Is it the intention of FreeELKS to restrict the implementation > freedom of other compilers in that way (e.g. I want to do garbage > collection with only 2 machine words of overhead)? > > With tecomp I want to implement a very runtime efficient and compact > form of garbage collection. However I have not yet found a way to > reconcile that garbage collector with the interference from FreeELKS. At some point we agreed with Manu that `base_address' should be built-in. And that's actually the way I implemented it in gec. I don't remember why Manu did not change it yet. Perhaps something related with Eiffel for .NET. You should know that EiffelStudio and gec don't have the same internal implementation for SPECIAL. In gec it's more like what you have in mind for tecomp. Features `count' and `element_size' are internally implemented as attributes, and then comes the items. SPECIAL.base_address is not the only place where EiffelStudio expects $ to point to the first item. Each time you have $a where `a' is dynamically attached to a SPECIAL it will have this behavior. In order to be interoperatable with EiffelStudio, what I had to do in gec is to have a special treatment for $. Internally it behaves as a dynamic call. Considering $a, if `a' is dynamically attached to a SPECIAL then gec returns the address of the first item, otherwise it returns the address of the object. This is not perfect, but in my experience this is what allows to compile and execute 99.9999% of existing code initally written with EiffelStudio. -- Eric Bezault mailto:[hidden email] http://www.gobosoft.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
|
helmut.brandl
|
Eric,
thank you for your response. As always your posts are straight to the point. Some remarks see below. Helmut The Eiffel Compiler http://www.sourceforge.net/projects/tecomp Documentation: http://tecomp.sourceforge.net Eric Bezault wrote: > Helmut Brandl wrote: >> It seems that the implementation of SPECIAL in FreeELKS has a strong >> impact on the underlying runtime system. >> >> It has a query "base_address" which is not builtin and returns the >> address of the special object. This requires from the runtime that >> the first object in the array starts aligned with the adress of the >> special object. So administrative information like the capacity and >> the element size cannot be stored within the object. >> >> It has a queries count and element_size which are builtin. But >> according to the above restriction, the runtime cannot store that >> information in the object. It has to store it somewhere outside the >> object. Probably Eiffelstudio and gec store that information in the >> garbage collection tag. Is it the intention of FreeELKS to restrict >> the implementation freedom of other compilers in that way (e.g. I >> want to do garbage collection with only 2 machine words of overhead)? >> >> With tecomp I want to implement a very runtime efficient and compact >> form of garbage collection. However I have not yet found a way to >> reconcile that garbage collector with the interference from FreeELKS. > > At some point we agreed with Manu that `base_address' should be > built-in. And that's actually the way I implemented it in gec. that feature you seem to use your builtin regardless whether there is an Eiffel implementation of that feature (if yes, you override it). Did I get it right? Maybe I have to do the same in tecomp to be able to compile FreeELKS. Currently I search for builtins only if the feature is marked as "external builtin" in the source code. Therefore I cannot override an existing Eiffel implementation (and no "external C" either). But I would prefer a FreeELKS which is not tied to a specific compiler to that degree. But as said before, if you confront theory with reality, reality usually wins (sometimes unfortunately, but that is live) ;-) > > I don't remember why Manu did not change it yet. Perhaps something > related with Eiffel for .NET. > > You should know that EiffelStudio and gec don't have the same > internal implementation for SPECIAL. In gec it's more like > what you have in mind for tecomp. Features `count' and `element_size' > are internally implemented as attributes, and then comes the items. Just for curiosity: How does Eiffelstudio handle the count and element_size? It has to store it somewhere with the object. Since Eiffelstudio has 2 levels of dereferencing (for its copying garbage collector) it could store it also together with the second pointer to the object. But that would imply, that each pointer to any object has a count and an element-size attribute. That would be an enormous overhead if you have an application with many small objects. > SPECIAL.base_address is not the only place where EiffelStudio > expects $ to point to the first item. Each time you have $a > where `a' is dynamically attached to a SPECIAL it will have this > behavior. I can imagine the reason: The main reason for having the $ operator is to pass addresses to C. Since in C arrays are pointers to the first element, that requirement is reasonable. Unfortunately there seems to be no written requirement for that in the ECMA specification. The more I dig into the implementation of an Eiffel compiler, the less I regard the ECMA specification as a good reference. > In order to be interoperatable with EiffelStudio, what > I had to do in gec is to have a special treatment for $. Internally > it behaves as a dynamic call. Considering $a, if `a' is dynamically > attached to a SPECIAL then gec returns the address of the first item, > otherwise it returns the address of the object. This is not perfect, > but in my experience this is what allows to compile and execute > 99.9999% of existing code initally written with EiffelStudio. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ freeelks-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freeelks-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
