tecomp 0.6 released
Helmut
tecomp is a command line compiler for the Eiffel language. It
implements standard Eiffel. In its simplest configuration it works
like an interpreter. It parses the Eiffel source code, validates it
and executes it in its virtual machine.
New features:
- INTEGER_8/16/32/64, NATURAL_8/16/32/64, REAL_32/64
- conversion
- virtual machine is architecture independant (i.e. for Intel, SPARC,
PowerPC, Motorola, ...)
Details: http://tecomp.sourceforge.net.
Download: http://www.sourceforge.net/projects/tecomp
scholz...@gmail.com
Okay i downloaded and tried it.
You should get rid of this
../../src/class/command_dispatcher.h:460: warning: ‘class
command_ass_chk<routine_descriptor_t>’ has virtual functions but non-
virtual destructor
../../src/class/command_dispatcher.h: In instantiation of
‘command_ass_loop<routine_descriptor_t>’:
../../src/class/command_dispatcher.h:704: instantiated from
‘command_dispatcher_t<routine_descriptor_t>’
warning. Otherwise it compiled fine on my older Ubuntu Linux.
I looked around and run a few of the examples without anything to
report.
At the moment i would just recommend that you change the license (now
where you still can). Move to a BSD type license or the Eiffel
license from the GOBO project. I like the idea of having an eiffel
interpreter and hope it is at some point in the future embeddable into
another application. We had the amber project before who tried to do
this - but the project failed.
When it is embeddable a GPL and for me even a LGPL is not acceptable.
And my further participation on this project will depend on this
issue.
Helmut
Hello Lothar,
thank you for your feedback.
With respect to the license issue: I am not an expert in licenses. So
help me a little bit. If you want to embed the eiffel compiler into
another application which is not GPL, I understand, that you cannot
accept GPL. But I don't understand why you cannot accept LGPL. The Gnu
C++ STL is released under LGPL and used by thousands of proprietary
commercial applications.
My questions:
What can you do with BSD which you cannot do with (L)GPL?
What does that mean for your specific project? (If you can, could you
disclose some information of the project you have in mind?).
I want to make tecomp as usable as possible. Therefore I don't have
any reason to constrain its use with a license. However I have some
plans for future extensions of tecomp and I don't want the license to
constrain me. Let me explain one of my plans.
Currently tecomp works as an interpreter and compilation to C will
come after implementing the full Eiffel standard. But I try to
integrate tecomp into either gcc or llvm. Technically I love the
functionality of llvm but from a penetration point of view gcc might
be more attractive. Since "integration" means linking, I must have a
compatible license.
This might not be a problem, because I as the author can release
tecomp under different licenses, one for public use and one for
integration into gcc or llvm.
Could you give me some advice an that issue.
Regards
Helmut
scholz...@gmail.com
> What can you do with BSD which you cannot do with (L)GPL?
If the community (or in this case the only maintainer) drops the
product you can try to maintain it and refinance it by turning it
into a commercial product and sharing the development cost of it
in this way. The idiots of Visual Eiffel didn't like this and so the
whole now GPL project is just more bits in the giant sourceforge
trashcan.
I learned this because i made the huge mistake with FOX and
SmallEiffel,
two projects where i have to spend a lot of time on development.
Communitiy died or went total crazy.
So if the part is mission critical then for me i will never ever use
LGPL again.
Also, LGPL for a runtime library is not really clever, you have to
allow reverse engineering (for some projects this is surely a
killer) ,
provide linkable executables (a lot of extra work, so some people
extend LGPL it with a static linking clause) and when using
C++ or C with inline functions the whole LGPL concept is quite
stupid.
Remember you are not Sun and this project will never reach a big
community
big enough to be able to survive. So for me it is 100% important
to give the project a BSD license.
I'm not sure how to continue. I don't want to drop Eiffel, i can't
to purchase EiffelStudio for 15000 US$, gec will never be useable
for large eiffel projects just for the same reason why i can't use
SmallEiffel anymore.
I'm also 90% sure that tecomp can't do it because they all suffer
from
a huge problem: Compilation time with a stupid simple command line
one
system at once compiler is larger the O(n). Also "gec" and "Small/
SmartEiffel"
are producing extremely large binaries. My programm with 300KLoc
compiles
into a 38MB executable at the moment (using SmallEiffel). This is
insane.
I don't see any ideas in your design to provide a compile server
(keeping
whole system information across compilation runs) or any way to at
least
just use more CPU cores to speed the compilation up. And no - you
can't add
this later. The whole system has to be designed from ground up for
this.
> What does that mean for your specific project? (If you can, could you
> disclose some information of the project you have in mind?).
Rewriting Eclipse or NetBeans.
> This might not be a problem, because I as the author can release
> tecomp under different licenses, one for public use and one for
> integration into gcc or llvm.
Yes if you change the license before you receive patches from other
people.
A dual license would be good enough.
And by the way. Have you ever looked at GCC ? It's a nightmare and
with eiffel there are more options, the easiest is to just generate
clever splitted ANSI C code. No need to write a GNU frontend.
There are 100 reasons why the GCC stuff should be avoided as hell.
Read the threads about using PCC for OpenBSD to get a few points.
Simon Willcocks
scholz...@gmail.com wrote:
> On 6 Dez., 14:44, Helmut <helmut.bra...@gmx.net> wrote:
>
> > What can you do with BSD which you cannot do with (L)GPL?
>
> If the community (or in this case the only maintainer) drops the
> product you can try to maintain it and refinance it by turning it
> into a commercial product and sharing the development cost of it
> in this way.
I can't claim any expertise on the (L)GPL, but a few thoughts spring to
mind:
1. People wouldn't have to wait for the original developer to drop the
project to take it and make money from it. (I'm not saying that's what you
would do, or that it's a danger for this particular project, but I'd be
pretty upset if I put in months or years of work into a project for free and
someone else tied a ribbon around it and sold my work without giving me a
penny.)
2. If you develop a significant commercial application that uses an LGPL
library, the money you make from that combination should cover the
development costs of your application *and* modifications you need made to
the library. You just have to feed back the modifications to the library
(or even pay developers to make the modifications) which means the library
developers get some benefit from the sale of their work.
3. I think you can fork a (L)GPL project at the point where it was still
"good" (in your opinion), and carry on from there; in which case you've lost
nothing. If your version is really much better than where the other has
gone, developers may switch over to your version.
4. If the starting point of the LGPL project isn't suitable for what you
want, you are probably better off writing your own from scratch with
whatever licence you want.
5. Calling people names is rarely constructive.
Simon
--
ROLF - The RISC OS Look and Feel on Linux.
http://stoppers.drobe.co.uk
http://ro-lookandfeel.blogspot.com/
Helmut
An answer to the licensing issue:
I have "googled" a little bit around to learn something about the
differences between BSD and GPL. I do not yet fully understand the
thing, but my first impression is that you have got a point. Since you
are not the first one asking me to change the license, I will
seriously consider it. Just give me some time (1-2 months, because
licensing is not on the top of my list) to understand the issue
better. You will get an answer to your request soon.
Regards
Helmut
Helmut
Hello Lothar,
an answer to your technical concerns:
I don't understand why other Eiffel compilers produce that large
binaries. If you write a simple "Hello world"-program, the binary
should have nearly the same size as the same program written in plain
C (at least if compiled as optimized). An optimized to C compilation
should just translate the Eiffel code to plain C and nothing more.
If you want garbage collection, you get some overhead for it (but it
is a rather small offset, nothing that grows with the code).
If you want exception handling, you will get some (code proportional)
overhead, but I wouldn't expect more than 10%.
If you want incremental compilation to C, you will get some overhead.
But only if you want to exploit the really minimum of recompilation
(e.g. treat all feature calls with dynamic bind, even if not necessary
in the current version but to avoid recompilation for future
versions). But I am in favor of doing incremental compilation not on
the C level, but on the intermediate code.
You see that I have some ifs, but I don't expect large binaries for
Eiffel code compiled with tecomp. Having not yet done compilation to
C, you might put a question mark on that statement. But remember: One
of the reasons to start the tecomp project was that the big footprint
of C-code and binaries of some competitors horrified me.
With respect to support fast edit-compile-run cycles: Yes, the
internal structures of tecomp are designed to support saving of
compilation results between compilation runs. I have not yet decided
if I will do it with a compile server, but compilations will not be
wasted and recompilations will only be done, if necessary.
Some of my measurement have shown that after parsing and validation
(which are class local without doing global analysis) there is a good
point to save the results. Parsing is very fast, but validation needs
some time and should not be wasted across compilations.
In other compilers (EiffelStudio and SmartEiffel), C-compilation is
the bottleneck. I do not yet know the reason. If the reason is
inflated C output from the compiler, the point of attack is the C code
generator. But let's see.
Regards
Helmut
scholz...@gmail.com
> 1. People wouldn't have to wait for the original developer to drop the
> project to take it and make money from it. (I'm not saying that's what you
> would do, or that it's a danger for this particular project, but I'd be
> pretty upset if I put in months or years of work into a project for free and
> someone else tied a ribbon around it and sold my work without giving me a
> penny.)
Well the alternative is to let the project die. So your ideas, work
and glory is totally lost an forgotten.
Also you make the money on your work. And there need to be a lot of
work to
make a commercial project better then the free alternative.
This argument is also an example of enviousness. If you are not able
to or
don't need to make money why shouldn't other people do it.
Finally our whole scientifc society was build on this idea:
http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants
> 2. If you develop a significant commercial application that uses an LGPL
> library, the money you make from that combination should cover the
> development costs of your application *and* modifications you need made to
> the library. You just have to feed back the modifications to the library
> (or even pay developers to make the modifications) which means the library
> developers get some benefit from the sale of their work.
Well not all commerical applications make significant amounts of
money.
Especially when you look at programming tool vendors.
And the whole idea simply does not work. Even Julian Smart from
wxWidgets
confessed that this is not how the world is working. And wxWidgets is
much
more significant then any Eiffel compiler can ever be.
> 3. I think you can fork a (L)GPL project at the point where it was still
> "good" (in your opinion), and carry on from there; in which case you've lost
> nothing. If your version is really much better than where the other has
> gone, developers may switch over to your version.
Some here. It does not work in general. Just for projects with a very
huge
community and a very significant domain (and an almost monopol like
XFree86).
> 4. If the starting point of the LGPL project isn't suitable for what you
> want, you are probably better off writing your own from scratch with
> whatever licence you want.
Yes. I've already written the semantik validation pass of an eiffel
compiler
and have done a lot of work on a good runtime. But why shouldn't i
share my
precious time with others and try to make a living on things that are
not basic
infrastructure.
To clarify: There is no discussion about this point with me.
It's my decision and i will not change it.
I learned enough from Freetards FUD and there lies in the last
decade.
If you look back with an open minded analysis you see it is in the
majority
of cases a total desaster. So please shut up you envy greedy Freetard.
Go and bring the GPL'ed Visual Eiffel back to life.
scholz...@gmail.com
> I don't understand why other Eiffel compilers produce that large
> binaries. If you write a simple "Hello world"-program, the binary
> should have nearly the same size as the same program written in plain
> C (at least if compiled as optimized). An optimized to C compilation
> should just translate the Eiffel code to plain C and nothing more.
This means you haven't ever looked at the SmallEiffel code generation.
If you have class A with method "a" and classes B and C which are
subclasses of A that use this method it just means that the resulting
executable will have C code for A.a B.a C.a so it is already a tripled
amount of code. You don't need a lot brain cells to see that this
schema
is not working well when your code base grows. SmallEiffel works
pretty
well unless you are using a lot of inheritance.
And to be honest i find that inheritance is not the largest benefit
you
get from Eiffel. It's all about DbC, clean syntax, templates and GC.
> If you want garbage collection, you get some overhead for it (but it
> is a rather small offset, nothing that grows with the code).
Boehm GC is just a 65 kB DLL.
> In other compilers (EiffelStudio and SmartEiffel), C-compilation is
> the bottleneck. I do not yet know the reason. If the reason is
> inflated C output from the compiler, the point of attack is the C code
> generator. But let's see.
No not really. Here are my Smalleiffel numbers.
8-9 seconds for a "compile_to_c" generating
1.282.684 lines and 39.824.624 bytes of c code in 140 files.
It takes for MSVC 7.0 on a dual 3Ghz Core2Duo 20 seconds
to compile and link this stuff. For Linux i use a 3.4 version
of gcc and an overclocked quad 3GHz Q6600. It needs with -O0
which is fine for development 36 seconds. Of couse you need to
use precompiled headers (speed up of 10x on windows and
4x on linux).
This is a full build. The SmallEiffel which just wrapps c files
after compilation of some number of features. Works pretty well,
except when using agents or tuples. In this case the c step only
takes 2-4 seconds and is a 1/4 to 1/2 of the eiffel compilation
time.
Thats why i say the Eiffel step needs a lot more work. And well
i would like to use inheritance and many different classes as well.
But there is always the danger that i run the system into the ground.
Always remember the desaster with the Eiffel WxWidgets or Corba
Bindings. Terrible and total unuseable.
By the way the only thing i have done on the code generation
optimization from original SmallEiffel was to add precompiled
headers. This was enough to give me a speed boost i never expected
before.
The step from SmallEiffel to SmartEiffel was a desaster too.
Not only did they invent a different language. They made the whole
Eiffel compiler slower. A "compile_to_c" wsa growing from 13
seconds on my old machine to 72 seconds. And they didn't care
because the SmartEiffel Team never had any serious sized application.
Unforuntely i can't check my app against anything else then my
patched compiler because it is using a lot of extensions like builtin
preprocessor. I judge the gec and smarteiffel on the fact how much
code they use to compile itself. And these numbers are discouraging.
"gec" seems to be much better then other compilers but without
DbC and SmallEiffel like stack traces i would never think about using
it.
Andrew Reilly
> If you want garbage collection, you get some overhead for it (but it is
> a rather small offset, nothing that grows with the code).
Some compilers/runtimes generate helper functions that know where the
pointers are, both in object records *and* in stack frames. This allows
exact, rather than conservative collection, I believe. This probably
introduces a code-proportional overhead. Of course this can probably be
data driven too: classic performance/size trade-off.
Cheers,
--
Andrew
Helmut
> On 7 Dez., 18:02, Helmut <helmut.bra...@gmx.net> wrote:
>
> > I don't understand why other Eiffel compilers produce that large
> > binaries. If you write a simple "Hello world"-program, the binary
> > should have nearly the same size as the same program written in plain
> > C (at least if compiled as optimized). An optimized to C compilation
> > should just translate the Eiffel code to plain C and nothing more.
>
> This means you haven't ever looked at the SmallEiffel code generation.
> If you have class A with method "a" and classes B and C which are
> subclasses of A that use this method it just means that the resulting
> executable will have C code for A.a B.a C.a so it is already a tripled
> amount of code. You don't need a lot brain cells to see that this
> schema
> is not working well when your code base grows. SmallEiffel works
> pretty
> well unless you are using a lot of inheritance.
Sorry. I wanted to say "I don't understand we they do it that way". I
didn't express myself well. It is not necessary to compile new C
functions in case of inheritance. It is only necessary if
- you want the utmost performance
- all classes have real objects and the feature "a" is really called
- the object layout for the class or the stack layout for the routine
is different
If you compile for non-optimized the conditions 2 and 3 for itself do
not require code duplication.
Only if all 3 conditions are true there a different c functions.
Otherwise it is not necessary. For the tecomp virtual machine I use
only one code for one body. No code duplication. Not even for generic
classes.
>
> And to be honest i find that inheritance is not the largest benefit
> you
> get from Eiffel. It's all about DbC, clean syntax, templates and GC.
Fully agreed. The sophisticated inheritance helps if you want to
design reusable libraries. In "application SW" you don't have a lot of
inheritance and very rarely multiple inheritance.
>
> > If you want garbage collection, you get some overhead for it (but it
> > is a rather small offset, nothing that grows with the code).
>
> Boehm GC is just a 65 kB DLL.
That's what I have said. A (comparatively) small overhead.
>
> Thats why i say the Eiffel step needs a lot more work. And well
> i would like to use inheritance and many different classes as well.
> But there is always the danger that i run the system into the ground.
> Always remember the desaster with the Eiffel WxWidgets or Corba
> Bindings. Terrible and total unuseable.
I think the Eiffel step is pretty under control in tecomp. Parsing and
validation is very fast. But I must admit that tecomp is not yet a
mature project. There are not yet big real life applications done with
tecomp. But try some examples and compare the compilation speed with
other compilers (Use `tecomp -ws2 acefile' to get the time spent in
different phases). I am sure that tecomp can compete on that issue
very well.
Regards
Helmut
Helmut
Hello Andrew,
from my point of view you don't need code proportional information if
you want to do "exact" garbage collection. The only thing you need is
layout information about the objects (i.e. is an attribute of an
object an expanded type object or a pointer?). Conservative collection
does not need that information. It looks at each word on the stack as
a potential pointer to an object. Therefore it is possible to mark
objects as "referenced" because of an integer on the stack that by
coincidence interpreted as a pointer "points" to a dead object.
Regards
Helmut
scholz...@gmail.com
By the way. How is it possible to do some linking to C libraries
with the tecomp interpreter?
I would suggest to invent a few better ways to interface to
C/C++. One of the extensions is very simple and important if you
ever want to wrap around a script language: Creating raw C strings
to pass to external features. I added a "raw" modifier to string
literals in the same way as "once" is working. This raw modifier
just creates a C pointer.
In an advanced way would also like to use static libraries - which
would require the generation of a DLL/so file in the background which
is then loaded into the interpreter.
Helmut
In order to respond to your request I need some more detailed
information of your needs. If you want to "load" something into the
interpreter without recompiling the virtual machine the only way I can
imagine is to load dll/so's (e.g. with the dlopen facility of
binutils).
Regards
Helmut
scholz...@gmail.com
> In order to respond to your request I need some more detailed
> information of your needs. If you want to "load" something into the
> interpreter without recompiling the virtual machine the only way I can
> imagine is to load dll/so's (e.g. with the dlopen facility of
> binutils).
I ordered a MacPro for Christmas and plan to start working on a
Cocoa Eiffel Binding. Once you have agents implemented i think it
could
be a nice test case for tecomp.
I will wrap the Coca stuff behind a ANSI C interface. So i just need
an
'external "C"' implementation.
A special setting in the ace file which points to the full so file
path name
you can dlopen would be fine. I don't think that performance is
serious, so
just doing a dlsym on all loaded files and caching the lookup result
should be working well enough.
Do you have any way to use c functions when i compile the virtual
machine?
For example a build tool that traverses a cluster and lookes for
external
declared features and make them accessible?
There are a lot of ideas in my mind how you could do this. Everything
is fine
for me as long as i'm not trapped in your Eiffel universe.
Simon Willcocks
scholz...@gmail.com wrote:
> To clarify: There is no discussion about this point with me.
> It's my decision and i will not change it.
I'm not asking you to change your decision, but you are asking Helmut to.
I suppose it comes down to how much help he can expect from you, and whether
he'd be willing to accept the abuse that I suspect you will be sending his
way.
> I learned enough from Freetards FUD and there lies in the last
> decade.
See below.
> If you look back with an open minded analysis you see it is in the
> majority of cases a total desaster.
That begs the question: does BSD licenced code have a better track record?
I seriously don't know, perhaps it does.
> So please shut up you envy greedy Freetard.
I'll just refer back to my final point, which you snipped:
5. Calling people names is rarely constructive.
I'm not the one wanting something for nothing, here.
Simon Willcocks
Helmut <helmut...@gmx.net> wrote:
> On Dec 7, 4:51 pm, Andrew Reilly <andrew-newsp...@areilly.bpc-
> users.org> wrote:
> > On Sun, 07 Dec 2008 09:02:12 -0800, Helmut wrote:
> > > If you want garbage collection, you get some overhead for it (but it is
> > > a rather small offset, nothing that grows with the code).
> >
> > Some compilers/runtimes generate helper functions that know where the
> > pointers are, both in object records *and* in stack frames. This allows
> > exact, rather than conservative collection, I believe. This probably
> > introduces a code-proportional overhead.
[snip]
>
> from my point of view you don't need code proportional information if
> you want to do "exact" garbage collection. The only thing you need is
> layout information about the objects (i.e. is an attribute of an
> object an expanded type object or a pointer?). Conservative collection
> does not need that information. It looks at each word on the stack as
> a potential pointer to an object. Therefore it is possible to mark
> objects as "referenced" because of an integer on the stack that by
> coincidence interpreted as a pointer "points" to a dead object.
It would be class-proportional, rather than code-proportional, then.
Presumably, you could get the compiler to gather all local references in a
routine together on the stack, with a count at the start, which would allow
the GC to just walk up the stack, checking references only.
I could be wrong, but doesn't the Boehm GC consider pointers into the middle
of an object as references to the object, as well as pointers to the start?
(I expect that even if it does, it can be turned off, though.)
Helmut
wrote:
> In message <6fcf80b6-17b1-49d7-abcd-69a1c8d5c...@v13g2000yqm.googlegroups.com>
I plan to do exact garbage collection using the object layout and
stack layout information. With that, garbage collection is pretty
straightforward. It will be implemented in one of the next 2 releases.
Pointing to the middle of objects is not possible in Eiffel, therefore
it is not a problem. I think Boehm GC has to do it like you have said,
because in C/C++ you can point to the middle of objects. Not
recognizing an object of this kind as life would be desastrous.
Regards
Helmut
Helmut
> On 9 Dez., 01:11, Helmut <helmut.bra...@gmx.net> wrote:
>
> > In order to respond to your request I need some more detailed
> > information of your needs. If you want to "load" something into the
> > interpreter without recompiling the virtual machine the only way I can
> > imagine is to load dll/so's (e.g. with the dlopen facility of
> > binutils).
>
> I ordered a MacPro for Christmas and plan to start working on a
> Cocoa Eiffel Binding. Once you have agents implemented i think it
> could
> be a nice test case for tecomp.
Keep me informed about the status of your project. As soon as possible
I would love to do the test. But before implementing external "C", I
prefer to complete the language. But the next step will be compilation
to C and all the related issues (linking, etc.).
>
> I will wrap the Coca stuff behind a ANSI C interface. So i just need
> an
> 'external "C"' implementation.
>
> A special setting in the ace file which points to the full so file
> path name
> you can dlopen would be fine. I don't think that performance is
> serious, so
> just doing a dlsym on all loaded files and caching the lookup result
> should be working well enough.
>
> Do you have any way to use c functions when i compile the virtual
> machine?
> For example a build tool that traverses a cluster and lookes for
> external
> declared features and make them accessible?
>
> There are a lot of ideas in my mind how you could do this. Everything
> is fine
> for me as long as i'm not trapped in your Eiffel universe.
Could you explain that a little bit? I don't understand what you mean.
Helmut
Hello Lothar,
I have given the licensing issue some more thoughts and come to the
conclusion that you have got a good point.
I am going the change the license of tecomp from GPL to a bsd like
licence (modified BSD or MIT or similar) in one of the next releases.
Kind regards
Helmut