contents

Introduction - 1

History - 2

Overview - 3

Advanced features - 4

Work in progress - 5

One possibility - 6

Conclusion - 7

References

Appendix 1 - blowfish

Appendix 2 - tkspline

5.1 - Additional Languages and Compilers

Arjen Markus has started work on modularising the compiler interface - to allow definition of  compilers, linkers and other build tools in a generic way. This has been used to provide a "proof-of-concept" version of Critcl that works on Windows with Microsoft Visual C.  It could equally be used to interface with proprietary C compilers, which often deliver better object code that gcc (for example,  the Solaris C compiler).

But it turns out that Critcl is not just a way to bind to C code, it just offers a means to wrap compilation of other languages, with a bit of automation for all glue aspects.

Arjen Markus has also used the modular build system to in apply the concepts of Critcl binding with Fortran source code:

   critclf::fproc nop {} void {
      return
   }
  
   critclf::fproc iadd {int x int y} int {
      iadd = x + y
      return
   }  
   critclf::fproc cube {int x} int {
      cube = x * x * x
      return
   }

Increasingly, however, users do not have a C compiler available nor the time or inclination to install one. This is especially true of Windows users. Work is currently underway to build a suite of gcc cross-compilers for common platforms (most likely Windows, Linux and MacOS X). These would be self-contained, stripped of unnecessary components to reduce the size and installed in a standard location that Critcl knows about. This would make it much easier for a novice Critcl user on any of the above platforms to generate packages for any of the platforms.

Alternatively, it may be possible to include a small compiler inside Critcl -  for the x86 architecture - so that for Windows and Linux no separate compiler is needed. This would be of benefit even if the included compiler generates inferior code, i.e. one could choose between "easy installation" and "more sophisticated compiler".

Another alternative being considered is to specify that a Tcl procedure should be compiled to bytecodes, and the bytecode included in the generated package. The incentive is not performance, but privacy. This would transparently integrate TclPro's [15] procomp and tbcload facilities.

For example,

   critclf::tcomp myproc {a1 a2} {
      # this will become bytecodes
      for {set i $a1} {$i < $a2} {incr i} {
           # do something sneaky
           ...
      }
   }

This would give the best of both worlds - important code could be protected (including, for example, licensing code) but the developer could still use Tcl rather than a compiled language.

see also

• Critcl Home Page

• Tclkit Home Page

• Starkit Home Page

• Wikit Home Page

• Tclers' Wiki

• Steve's Website

• Jean-Claude's Website

Paper by S. Landers & J.C. Wippler, as presented at Tcl/Tk 2002 conference - see also original PDF.