It seems that the CodeGear(Borland) has give up to continue researching the compiler domain, and has turned to develope application lifecycle management (ALM) products.
No-one cares the future orientation of the compiler and the language in the CodeGear(Borland) any more. No-one thinks to improve the performace of the compiler and the language in the CodeGear(Borland) any more.
The size of compiled binary files gets more and more bigger...

Only Delphi fans can do. So the KOL project had been appeared to reduce the size. the FastMM, FastCode projects had been appeared to improve the speed.

The CodeGear has been just following close behind the ass of the M$. It is a pity really.

Delphi fans of all countries, unite! Build the TurboCompiler Infrastructure Framework for ourself. Constructs the Common Object-Oriented Scripter/Compiler Language Infrastructure Framework.

I have to say, the M$ has been ahead of the researching the compiler domain. So I absorbe the merits of the M$ CLI(Ecma) and has Designed the TurboCompiler Infrastructure Framework.

Any comments are welcoming.

Purpose(Target):
    It must exceed the M$ CLI.
    It can be a Interpreter.
      You can write your Interpretor by youself.
      It's the fastest/smallest bytecode virtual machine.
    It can be a JITter like .Net.
      You can write your CLR(.Net) implementment like mono by youself.
    It can be an embeddable/Independence Compiler to generate the real machine code for processors.
      You can write your compiler by youself.
      You can add your new syntax by youself.
    It can be fully configurable.
      The Type System can be fully configurable and self-explained.
      It can be type-safety(StrongType): the types can have the typeInfo at runtime or not. (decided by youself!)
      It can be named type.  the types have the name of the type at runtime or not. (decided by youself!)
    ....

Features:
  * Highly Reusable Objects Engine
    * Clearly demarcated layers
    * Highly Separable.Components(Classes)
  * Highly Scalable Engine
    * Highly Configurable
      * StrongType Supports or not
      * The external function can Load On demand or PreLoad(Module).
      * Self-explained Common Type System.
      * distributed virtual machine.
    * the CLR can call the functions in DLL or Host.
    * the host can call any function in CLR.
    * Executor Class Configurable(choose freely)
      * Interpreter
      * JITter
  * Highly Extensible Engine
    Highly Extensible Common Type System: all types(include system types) can be defined by developer themself.
  * High Speed with small footprint.
  * Top Security

Roadmap:

I. The first Phase - Codename: TurboScript
  V 0.7[Done]: the simple execution efficiency test of the TurboScript and other script engines is here.
    TurboCompiler: TurboForthCompiler
    TurboSymbol
    TurboModule
    TurboExecutor: TTurboInterpreter, TTurboX86Interpreter
    TurboAppDomain
    TurboModule Loader: TTurboModule File Loader

  V 0.8:
    the Mini Compile-time/Runtime Core
    TurboPascalCompiler: TurboPascal RTL Library.
    TTurboModule DB Loader

  V1.0:
    TurboCSharpCompiler, TurboBasicCompiler ...
    TurboTranslator
    TTurboJITExecutor
    TurboDebuger
    TTurboModule Web Loader

  V1.1:
    Re-write the Mini Compile-time/Runtime Core with another languages(eg, C) to boot anther OS.

II. The Second Phase- Codename: TurboCompiler
  V2.0:
    TurboExecuteFileFormat: TurboExecuteFileFormat

III. The Third Phase - Codename: TurboUML
  V3.0: Design your all source code by UML editor like the Model Maker Tools. And generates the any supported high level language source code or compiles into execute binary file directly from UML automatically.

Layes:
  * TurboModule Compiler
    * TurboSymbol
    * TurboTranslator
    * TurboCompiler: compile the source into the TurboScript Virtual Machine code stream.
        TurboASMCompiler, TurboForthCompiler, TurboPascalCompiler, TurboCSharpCompiler, TurboBasicCompiler, etc
    * TurboExecuteFileFormat: encode the translated native code stream to executable file formats which the OS supported.
        TurboPEFileFormat, TurboELFFileFormat
  * TurboModule Executor
    * TurboModule
    * TurboExecutor
        TTurboInterpreter, TTurboX86Interpreter, TTurboJITExecutor
    * TurboAppDomain
    * TurboDebuger
  * TurboModule Loader
    * TTurboModule File Loader: load TurboScript module from File.
    * TTurboModule DB Loader  : load TurboScript module from DB.
    * TTurboModule Web Loader : load TurboScript module from Web.

TurboModule Layer:
  the TurboScript Virtual Machine code in the memory. It's the smallest TurboScript Virtual Machine code unit in the memory.
  the TurboModule can be treated as a CLR Static Class.

TurboCompiler Layer:
   The Turbo Compiler compile the source into the TurboScript Virtual Machine code stream.
  Core Layer:
    TurboSymbol:
      * Redesign the TurboSymbol Architecture(Compiler)
  Application Layer:
    V1.0: USE THE COCO/R
      Tokenizer, Parser(the COCO/R implemented. TODO: Modify the COCO/R source to speedup.)
      TurboASMCompiler, TurboForthCompiler, TurboPascalCompiler, TurboCSharpCompiler, TurboBasicCompiler:
        1. Translate the source to the TurboSymbols.
        2. save to file stream

TurboTranslator Layer: translate the Virtual Machine Code into native code.
  TurboTranslator:    abstract Translator
  TurboX86Translator: translate the Virtual Machine Code into the native code of X86 processors.
  TurboJitTranslator: translate the Virtual Machine Code into the simple genernal JITter native code.

TurboExecuteFileFormat: encode the translated native code stream to executable file formats which the OS supported.
  TurboExecuteFileFormat: abstract Executable Binary File Format.
  TurboPEFileFormat: Encode the native code to Windows PE File Format;
  TurboELFFileFormat: Encode the native code to Linux ELF File Format;

TurboExecutor Layer:
  The execution mechanism of the TurboScript Virtual Machine code stream.

  TTurboInterpreter:
  TTurboX86Interpreter: the fastest interpreter(X86 optimal).
  TTurboJITExecutor: the Just In Time(JIT) executor.
    JITter can be security of the Virtual Machine Code.

  TurboAppDomain: the minimal runable scrpiter unit.
   It manages a TurboModule and an TurboExecutor.

TurboAccessor Layer: load and manage TurboModules in the memory.
  TTurboAccessor: the pure abstract accessor class: the module accessor and ModuleManager are derived from it.
  TTurboModuleAccessor: Abstract TurboModule Accessor[singleton]
  TTurboModuleManager: The TurboScript Module Manager.
    the GTurboModuleManager global variable manages all the loaded(cached)
    modules. And register the new ModuleAccessor to GTurboModuleManager.

    Require method return the specified module. It first
    searches in the memory if not found, try load the module
    through registered module accessors.
  TTurboModuleFileAccessor: load TurboScript module from File.
  TTurboModuleDBAccessor: load TurboScript module from DB.
  TTurboModuleWebAccessor: load TurboScript module from Web.

Dependency Layers:

TurboCompiler --> TurboSymbol(symbol-tree) -->  TurboModule(Virtual Machine Code) --> TurboExecutor
                                                       ^
                                                       |
                                                       |
                                                   TurboAccessor

TurboExecutor [-->TurboTranslator(Real Machine Code) --> TurboExecuteFileFormat(executable binary file formt)]

TurboAppDomain__|--> TurboModule
                               |--> TurboExecutor