(I am the creator of C-FLEA)
C-FLEA uses a "virtual instruction set", which is essentially a byte code.
The ability to run code on a CPU without a native C compiler is only one
application - it is equally valid to use this tool to create single binaries
which run an vastly different target systems (I've used it for this purpose
in a number of applications).
Unlike JAVA, C-FLEA does not have a standard set of predefined user
interface functionality, however as long as you define an identical set of
virtual I/O devices and access functions on each target, you can accomplish
a similar target independance.
Could you plese elucidate this point
The point I'm trying to make is that within the concept of a virtual machine,
you have flexibility to implement pretty much any environment and features
that you wish - not just what one particular vendor may advocate.
And this one too.
Here's a clip from my FAQ on "what is C-FLEA":
- You can use C on ANY target system, even if a native code C compiler
is not available for it. All you have to do is to get a C-FLEA VM up
and running, and all of the C-FLEA tools and libraries will work.
- C-FLEA code is portable and platform independent. You can implement
C-FLEA VM's with similar I/O features on multiple (different) hardware
platforms, and then compile a single C-FLEA program which can be run
on all of them without requiring any changes or recompilation.
- Since you "write" the C-FLEA CPU, you can provide functionality that
cannot be achieved in a conventional system. Here are some ideas:
- Execute from non-standard memory (eg: serial)
- Encrypted memory and other Advanced security / protection schemes
- Specialized peripherals appearing as I/O ports
- Add your own instructions!
- Multitasking support right in the CPU
- Debug tracing, event traps, specialized breakpoints etc.
- C-FLEA code is very space efficient.
I see that, your website mentions that the VM is of about 1 kb
only.
The C-FLEA instruction set was
designed from the beginning to be ideal for a C implementation, and
as a result, you can pack a lot of C code into a fairly small image.
In most cases, programs compiled for C-FLEA will be SMALLER than the
same program compiled for a native CPU (Note: Since there is a memory
overhead for the C-FLEA VM code, the total memory required will only
be less for larger programs).
Thanks but I have one query bursting my brain, I don't know how to put
but try must I, "Why don't we have more of C-flea" why don't people
just share currently the C-Flea byte code like the Java byte code, It
is obvious to me that a CVM would be on any given day would be faster
than the JVM, so why sir may I ask of you why? Ok it is not only about
speed, people prefer OO for many reasons but there are a lot of people
of like C, and won't mind sharing .Cbytecode files. I mean if we have
speed, safety and stability of a CVM who in the world needs JVM, OO is
one reason but I mean we am talking about speed. Would you prefer to
sit on an "supercar" that required hard work but runs at the speed of
light[3*10^8 m/s] than a "car" that runs at 3*10^8 m/hr.
Too many question I guess.
I however apologize to the C gurus for me taking this discussion Way
off topic, but I don't know any other group where I could talk about
