[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oaw-wg] Xpand middleend and backend
- From: Sven Efftinge <sven.efftinge@xxxxxxxxx>
- Date: Wed, 27 Jan 2010 14:49:11 +0100
- Delivered-to: email@example.com
we should discuss Xpand related issues on the M2T developer list.
Please find my comments below.
As my example showed, the middleend and backend improve the code
generation performance for larger models. Even higher performance
improvement can be expected for larger models than I included in the
example as the convertion of the frontend AST to the backend AST
introduces some overhead that will be cut off when compiler is
Sounds good. I haven't yet found the time to have a look (Sorry).
Maybe it would be interesting for others to read some comparing numbers?
Furthermore the backend provides a foundation for further performance
improvements and integration with other languages such as OCL.
Therefore I propose to include the following bundles/features with
Xpand into the helios release:
Which version number should be given?
We're currently at 0.8.0.
The bundles should have their own feature, as well.
Some bugs are still to be fixed. These relate to the convertion of
the frontend typesystems for UML2 and XSD to their respective
backend typesystems. Currently a converter in the middleend converts
the types from frontend to backend. To go ahead with this approach,
I would have to add getters for the stereotypes in StereotypeType
Making those types inspectable shouldn't be a problem.
Arno proposed a better solution that results in less dependencies in
backend, avoiding to load all the typesystems, when they are not
needed. His solution was to add a method "asBackendType" to every
frontend type. Ideally every frontend type would implement an
interface introducing the method "asBackendType". Frontend types
would be better encapsulated then (meaning no additional getters). I
could take care for implementing this approach. Would you be fine
with the latter approach?
I think the current solution is nicer, since it does not create a
strict dependency between frontend and backend.
Having an indirection (middleend), which is responsible for providing
a backendtype seems to work well in both situations.
Later when the backend has been widely adopted, we could add the
mentioned getter and slim done the middleend to a minimum.
But even than I'ld prefer to stick with the middleend abstraction, so
it will be possible to integrate other languages with the backend
without changing them (at least as long as they are introspectable).
As I understood, bugfixes can still be done during the next
milestone. So I propose to include the bundles mentioned above into
the Helios release.
Would it be ok to do the build integration after Tuesday's M5?
It is only a couple of days and Dennis (our Release Engineer) won't
have any time to spend by then.
If we do the integration right after M5, there would be enough time to
face and fix any build issues.