Re[3]: [LLVMdev] Re: [Opencxx-users] LLVM and OpenC++

[Grzegorz J. <ja...@he...>]

Hi,

On Fri, 16 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] "  wrote:

> Hi all, hi Grzegorz
>
> > Valery, IMO your reply is slightly agressive.
>
> oh, there was no aggression implied in any form!
> i am sorry for inducing feelings like that :(

Sorry if I misread anything.

> > If you think JIT is imporant for OpenC++ project, please explain why.
>
> sure i'll try.
> below.
>
> Point 1. (C++ is static language, but some dynamics is possible via "new")
>
> Although C++ standard does not push implementer towards
> compiler-only language implementations still AFAIK all C++
> implementations are de facto  *compilers* and not
> iterpreters/JITs.

I know of at least one C++ interpretter, I don't remember the name now,
perhaps 'cint' ??? Let me know if you cannot find it with google (AFAIR it
has been announced at comp.compilers), I will try to dig it up.

> There is no things in C++ standards
> today, which might demand compilation in run-time.
> In practice, all run-time demands might be resolved with operator
> "new", i.e. dynamic object allocation. With C++ in
> run-time one can not create new types or new functions.

Sorry, this passage is unclear to me.

>
> Point 2. (OpenC++ is fully static, no dynamic is possible)
>
> Instantiation of metaclass object is not possible in run-time.
> Indeed this should demand run-time compilation of corresponding
> base level class and linking the code to already running code,
> which is not feasible with gcc.

Besides you hit problems with static typing. If a program can create a
metaobject during the run-time, then effectively it can add new class to
itself. Now how can the program use this class and how calls to this
class's methods can be typechecked?

> Point 3. (dynamics in OpenC++ would be a useful thing)
>
> Imagine that one has some command-line tool, where the *behaviour*
> of the running code is changing massively with options
> like "--verbose" or "--debug". Let's consider option
> "--debug" which tells us about every member function call
> and turns on some additional checks.
> A metaclass VerboseClass is a nice approach to
> introduce these different types of application's behaviour.
> But if for "--debug" and non "--debug" option we have the
> same code then non "--debug" version will never show
> perfect performance. Indeed, with every member function call
> one will obtain implicitly an extra statement like:
>
> SomeClass::SomeFunc
> {
>   if(debug_option_is_set)
>     // do output and additional checks
>   ...
> }
>
> which will cause (many) redundant checks in non "--debug"
> program invokation. And will disallow nice optimisations.
> One could say here: "why not to create at
> compile time all needed classes and then in run-time
> just invoke the corresponding one?".

What do you mean by "invoking a class" ?

> Well, it is a solution,
> but creating a code instance for an every command line
> option combination will blow up the code enormously.
>
> Point 4. (metaclasses are adequate to change class behaviour in run-time)
>
> Let's look into example above. The metaclass VerboseClass
> is a nice place to switch on/off verbose output.
> Even in run-time as well.
> But the problem is that VerboseClass will not make
> performance of non "--debug" invocation as good as
> possible. Because the code for  --debug  can t be recompiled.
>
> Point 5. (creating classes in run-time needs JITing/interpreter)
>
> Quite clear, that creating of new types/functions in
> run-time needs JITing/interpretation in run-time.
> Even worse: the recently compiled ready for execution
> modules should be bound somehow to already
> running code.
>
> Point 6. (LLVM could help to introduce JITing to OpenC++)
>
> what is LLVM one could read at this page:
> http://llvm.cs.uiuc.edu/
>
> Important here is that LLVM can also generate and manage
> code in run-time. In example above, after starting command line
> tool the corresponding classes might be created and *compiled*
> according to option like "--debug".
> Id est, compiled in run-time. Thus, one could expect that
> invocation without "--debug" will be as quick as possible,
> because classes instantiated without "--debug" option
> do *not* have any debug related code anymore.
>
> > A question: I can see you have an idea, but do you also have resources to
> > implement it?
>
> No.
> But at least I'd be happy to invest the idea and motivation.
>
>
> >  We (at least myself) can guide you through OpenC++
> > architecture, help with infrastructure, but that's it. In particular, do
> > you want to contribute your time into implementation of your idea?
>
> I just don't have enough free time for such a monster job :(

Cut off a smaller piece, set a reasonably small goal, write a prototype.

> Only such a brilliant guys like Chris Lattner, Moshe Bar,
> Linus Torvalds, ..., ...,  could bring such ideas to the
> life being full-time involved in that though.

If you create interesting technology, you can make it your check-paying
job at some point.

> > It
> > takes lots of advocacy work to make other people implement your ideas.
>
> You are right, but I should try at least to clear my conscience.
>
> > Unless you are a university professor, of course :-)
>
> hehe, not yet, not yet.

Valery!

For me it looks like you have a vision, but what you are proposing is a
huge project, much bigger than OpenC++ itself. I would be happy if you
build this project using OpenC++ or its components.

Your arguments make sense to me, however I feel that this discussion
becomes off-topic on this list. I suggest that you set up a separate
project on SF and let's move this discussion there. It would also be
helpful if you make your e-mail into a wrap-up and post on your project's
website as a kind of manifest. Perhaps you also would like your ideas
reviewed by posting to other forums, say, comp.compilers, if you haven't
already done it.

> > PS: I am not posting this e-mail to llvm dev list, as I find it to be OT
> >     there.
>
> right.
>
> BTW, as OpenC++ team the team of Chris Lattner makes
> a lot of changes to gcc and tracks gcc' versions.
> Maybe some communication between both teams might
> be fruitful?

What exactly do you have in mind?

>
> Have a nice day anyway!
>
> P.S. if this long letter will be lost again while sending process
> as its long predecessor then one will find again some
> traces of "aggression" in my short posts :)

:-)

BR
Grzegorz


##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################