Budding compiler writer(s) invited to a party!
Posted: Fri Nov 06, 2009 1:42 pm
Hi folks,
sorry, but this party comes with no drink, drugs, sex and definitely no rock and roll!
It does come with a money back guarantee however!
(Don't worry, no money is involved!)
Some background info first. My apologies for there being a lot of info to give, but I need to be absolutely clear up-front what this is all about!
My Arctic Reports system is in need of a 'scripting engine' in order to allow reports to carry their own 'code modules' (much like MS Access reports etc.) Because of this (and because of my never doing things by half or indeed taking a simple path through life) I have been working for some time now upon an entire 'framework' which can be used to create scripting engines or full programming languages etc. (It is all crossplatform.)
A consumer application (such as Arctic Reports) would build it's script engine (or programming language, e.g. I intend using what I have termed the 'cRun framework' to eventually build a CGI language as php annoys me somewhat!
) by adding a suitable run-time (built with PB or any other language for that matter) to those parts of the cRun framework which are appropriate for the underlying situation. You then compile this little lot (with PB) and voila - instant (and fully customised!) scripting engine. Simples!
Well, not quite simple, because the cRun framework is of course a complex little beastie.
To give some idea of how the cRun framework is intended to work; imagine my Arctic Reports system for a second. When this loads up a report, it will grab ahold of any 'code modules' attached to the report and will immediately compile them using a cRun compiler ready for execution. The result of this compilation is a cRun object file (which is both executable and linkable, but not in the x86 sense). When code from this object file is required to be executed (e.g. when a report is being previewed), the cRun 'execution layer' (built in to Arctic Reports) is invoked which executes the appropriate parts of the object file.
Adding this functionality to Arctic involves first creating a suitable run-time. For this I shall use PB and create a bunch of functions for accessing report properties etc. When this is done I add as much of the cRun framework to Arctic as is required. The components of the cRun framework (together with progress made towards their completion) are listed below :
) with full specs for the VM, object files, op-codes, assembly code etc. and all is working well right now. E.g. I have a suite of demo assembly code files which compile and execute flawlessly; including some which utilise run-times and even utilise callbacks within the ASM code etc.
Now, to business!
As you can see, I am yet to start work on my 'Slipstream' compiler (work will start as soon as I complete the debugger). I envisage this as offering a set of 'Basic keywords' (the usual stuff; If/EndIF, For/Next... etc.) but that is neither here of there really. The compiler will use the cRun assembler as it's back-end which itself takes care of a lot of the work. E.g. the assembler deals with all data-types, global and local variables and so on. The compiler need not offer more than a very basic set of commands, because the run-time(s) take care of the rest! E.g. the environment layer will add a standard (optional) run-time including some string functions etc.
I am thus inviting all parties interested in creating a 'minimal' compiler to 'hop on board' at this stage. This would not be a 'joint effort', but a chance for anyone interested in trying their hand at creating a compiler to do so in a very controlled environment. I would say, with good reason, that creating a cRun compiler would be much easier than creating a x86 compiler, for example, and is an excellent chance to hone your skills accordingly before perhaps stepping up to a full x86 compiler etc. I ask only now that this project is advanced to the point where a compiler is now the next natural step as the assembler is looking good and working far better than even I imagined it would!
My reasons for asking are two-fold. First, well, the more cRun compilers that are available the better for myself and the cRun framework. Second, and more selfishly perhaps, I have never written a compiler before and I have no idea if my Slipstream compiler will be a success or not? In the event of my failing to produce a decent compiler, well, I may at least be able to purchase a license (or whatever) for someone else's compiler. In fact, I would be more than happy to do so.
I will add that all the specs come in the form of very short text files and I think are easy to follow. Combine this with the suite of demo ASM files (and PB programs showing how to assemble and execute the resulting object code etc.) and I reckon that an experienced coder would be up and running within a few hours. Prospective compiler writers would not need to concern themselves with the format of the object files (for example) as the cRun assembler handles all of that. You would just need to know how to use the cRun framework and to understand the VM (stack based machine) and the cRun assembly code. All of which are simple (that or your money back!)
Please don't hesitate to contact me through e-mail, pm or even here in this thread if you require more info or would like to see the specs etc. In fact I shall probably upload the specs somewhere so that anyone can read them.
Regards.
Stephen.
sorry, but this party comes with no drink, drugs, sex and definitely no rock and roll!
It does come with a money back guarantee however!
(Don't worry, no money is involved!)Some background info first. My apologies for there being a lot of info to give, but I need to be absolutely clear up-front what this is all about!
My Arctic Reports system is in need of a 'scripting engine' in order to allow reports to carry their own 'code modules' (much like MS Access reports etc.) Because of this (and because of my never doing things by half or indeed taking a simple path through life) I have been working for some time now upon an entire 'framework' which can be used to create scripting engines or full programming languages etc. (It is all crossplatform.)
A consumer application (such as Arctic Reports) would build it's script engine (or programming language, e.g. I intend using what I have termed the 'cRun framework' to eventually build a CGI language as php annoys me somewhat!
) by adding a suitable run-time (built with PB or any other language for that matter) to those parts of the cRun framework which are appropriate for the underlying situation. You then compile this little lot (with PB) and voila - instant (and fully customised!) scripting engine. Simples! Well, not quite simple, because the cRun framework is of course a complex little beastie.
To give some idea of how the cRun framework is intended to work; imagine my Arctic Reports system for a second. When this loads up a report, it will grab ahold of any 'code modules' attached to the report and will immediately compile them using a cRun compiler ready for execution. The result of this compilation is a cRun object file (which is both executable and linkable, but not in the x86 sense). When code from this object file is required to be executed (e.g. when a report is being previewed), the cRun 'execution layer' (built in to Arctic Reports) is invoked which executes the appropriate parts of the object file.
Adding this functionality to Arctic involves first creating a suitable run-time. For this I shall use PB and create a bunch of functions for accessing report properties etc. When this is done I add as much of the cRun framework to Arctic as is required. The components of the cRun framework (together with progress made towards their completion) are listed below :
- The 'Environment' layer.
A requirement for all consumers of the cRun framework. Allows the consumer to register a run-time.
Status : Complete but for the addition of the standard run-time which I can add at any time. - The 'Slipstream' compiler.
A 'minimalist' compiler making use of the cRun assembler to create cRun object files. Consumers can make use of this compiler or can use any 3-rd party cRun compiler.
Status : Not started. - The cRun assembler/linker.
Creates cRun object files from cRun assembly code and can add code (statically link) from other object files.
Status : 95% complete. - The 'Execution' layer.
Responsible for executing code within cRun object files, handling parameters and return values.
Executes code against what is a 'virtual machine' (much like .Net's VM) which is a stack based machine.
Status : Complete. - An external 'standalone' debugger.
A consumer of the cRun framework in that this is intended as a standalone tool. Integrated debuggers can easily be created by consumer applications to function as a part of that application. This tool, however, is intended as a separate utility.
Status : Just started work.
) with full specs for the VM, object files, op-codes, assembly code etc. and all is working well right now. E.g. I have a suite of demo assembly code files which compile and execute flawlessly; including some which utilise run-times and even utilise callbacks within the ASM code etc.Now, to business!
As you can see, I am yet to start work on my 'Slipstream' compiler (work will start as soon as I complete the debugger). I envisage this as offering a set of 'Basic keywords' (the usual stuff; If/EndIF, For/Next... etc.) but that is neither here of there really. The compiler will use the cRun assembler as it's back-end which itself takes care of a lot of the work. E.g. the assembler deals with all data-types, global and local variables and so on. The compiler need not offer more than a very basic set of commands, because the run-time(s) take care of the rest! E.g. the environment layer will add a standard (optional) run-time including some string functions etc.
I am thus inviting all parties interested in creating a 'minimal' compiler to 'hop on board' at this stage. This would not be a 'joint effort', but a chance for anyone interested in trying their hand at creating a compiler to do so in a very controlled environment. I would say, with good reason, that creating a cRun compiler would be much easier than creating a x86 compiler, for example, and is an excellent chance to hone your skills accordingly before perhaps stepping up to a full x86 compiler etc. I ask only now that this project is advanced to the point where a compiler is now the next natural step as the assembler is looking good and working far better than even I imagined it would!
My reasons for asking are two-fold. First, well, the more cRun compilers that are available the better for myself and the cRun framework. Second, and more selfishly perhaps, I have never written a compiler before and I have no idea if my Slipstream compiler will be a success or not? In the event of my failing to produce a decent compiler, well, I may at least be able to purchase a license (or whatever) for someone else's compiler. In fact, I would be more than happy to do so.
I will add that all the specs come in the form of very short text files and I think are easy to follow. Combine this with the suite of demo ASM files (and PB programs showing how to assemble and execute the resulting object code etc.) and I reckon that an experienced coder would be up and running within a few hours. Prospective compiler writers would not need to concern themselves with the format of the object files (for example) as the cRun assembler handles all of that. You would just need to know how to use the cRun framework and to understand the VM (stack based machine) and the cRun assembly code. All of which are simple (that or your money back!)
Please don't hesitate to contact me through e-mail, pm or even here in this thread if you require more info or would like to see the specs etc. In fact I shall probably upload the specs somewhere so that anyone can read them.
Regards.
Stephen.
