CAlive is coalescing

[Rick C. Hodgin]

I wrote some information about this on the comp.lang.c group:

https://groups.google.com/d/msg/comp.lang.c/g2SQtKLb5tA/GttChkh0AQAJ

Here is the content copied:

-----[ Begin ]-----
As the design stage of CAlive progresses, I can see light at the end
of the tunnel. Still much to do, but there is a goal in sight, a
series of steps to get there. There are very few details left to
work out for a 32-bit 80386+ implementation of its design. After
that, it's on to coding and debugging the RDC framework CAlive will
use for its creation.

CAlive could be generating production binary code by the end of 2019
in its own new RDC framework, with other languages following quickly
thereafter.

If I were prone to celebrating milestones, I might do that about now.

I'm so excited about CAlive. It's what I've always wanted in a
programming language. Powerful base abilities. Fully extensible.
The ability to fully incorporate edit-and-continue at all stages
(I call it "LiveCode"), and the ability to have a known relationship
between a developer and the IDE environment it's being run in,
allowing for the new concept of an inquiry which suspends to the
debugger to ask what to do when something unexpected happens,
rather than just stopping with an error.

May the Lord guide me forward on this project. May I give Him my
best, so that all of you can benefit from my labor.

Thank you,
Rick C. Hodgin

-----
As a reminder, CAlive is a language design for a C-like language that
adds the basic class and exception handling. It's built inside the
RDC framework, which is something like a base set of abilities driven
by a database that allows compilers to be written within it.

RDC exposes a core set of necessary processing abilities that a
language needs to parse command line options, read in data files,
and translate raw source code through a series of stages ultimately
into binary code.

The CAlive language is essentially just a database plugged in to
RDC which guides its operation during compilation. As such, there
is no true CAlive compiler as a native, stand-alone thing. It is
only using RDC with a CAlive database enabling it to compile CAlive
source code. And similarly, other databases can be created which
guide RDC to compile other source code.

From the user's perspective, CAlive will be of the traditional form:

calive myfile.ca

This will invoke the RDC framework via the calive.exe program which
contains its own database. It loads RDC and passes the database to
it. RDC reads the database and basically takes over processing from
that point forward. It parses the command line, loads any data files
that are indicated, and begins the steps within the database which
instruct it to process code through line-by-line, section-by-section
from source code, through to object code, with a linker ability for
multiple target forms, though the stages involved are entirely free-
flow, dependent upon what the database guides it toward.

RDC will also be able to natively intermix languages from a single
source file when their databases are present (when the indicated
languages have been coded and designed). It will work like this:

// By default, the compiler uses whatever language it was
// invoked with. For calive.exe, it will use CAlive code.
// To use other libraries, use a form with _ and then the
// language name. Languages used can also be nested as
// needed.

_lisp {
// Lisp code here
}

_fortran {
// Fortran code here
}

_java {
// Java code here
}

The code within each block is compiled by the appropriate language
database, and since RDC resolves everything down to fundamental data
types internally, data exchange between languages will be possible
at all points.
-----[ End ]-----

Somebody stated that targeting an obsolete 32-bit architecture
didn't seem to make much sense. My reply speaks of part of the
long-term plan I have for this project. I'm not just creating
a new programming language or new compiler framework, but it is
a desire to create an entire hardware and software stack devoted
to the Lord, meaning we acknowledge Him as the source of our
skills and abilities, and we acknowledge Him as the head and Lord
of our lives, and we then reach out to other people teaching them
the same thing He first taught us, that His love in giving is for
us to do for others when we have the opportunity:

-----[ Begin ]-----
I am creating a new hardware architecture called Arxoda. It's based
on the 80386 design extended out to 40-bits, but with a much larger
register set. It employs something I call a WEX (Window register
extensions).

WEX indicates which set of base 80386 register encodings are used
in conjunction with the WEX setting to access that register group
within the larger register set to process data:


http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/wex_register_mapping.png


The overall architecture design is here:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core

I also have a simplified Arxoda design I call Arxita, which I'll
design and implement first. It is basically a 5-stage pipeline
80386, based on my original Oppie-2 design, using the same opera-
tional environment, but without protected mode, paging, and no 16-
bit support. It will introduce a simplified floating point engine,
and basically be a 32-bit protected mode core that uses a different
opcode encoding with some new instructions that will ultimately be
found in Arxoda:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxita

-----
My goals are not just 32-bit 80386, but are in progress toward usable
code in today's operating systems on today's processors, purposeful
code toward my own operating system running on Arxita, with the final
goal being running native code on my own 40-bit Arxoda CPU, with a
full hardware and software stack given over to God, lifting (meaning
acknowledging) Him in the design, and then giving it out to mankind
for general use.

My goals are to honor God with the skills He's given me, and to give
the people around me real tools they can take, alter, extend, adding
their own special and unique abilities atop.
-----[ End ]-----

Someone else replied that I was using a C++ compiler to compile my
CAlive code, and that it didn't make sense for me to post about it
in a C group. I replied that CAlive is basically C with the basic
class added, and exceptions, and some new things. I also indicated
that I eventually intend to have a fully compliant C90 and C99
implementation that CAlive will be able to compile with.

-----[ Begin ]-----
CAlive is being written in a form that CAlive will later natively
compile itself. It is my goal to have CAlive bootstrap itself.

CAlive is beyond C, so I have no choice but to compile it in a C++
compiler, but even so I don't use much C++. In fact, I use almost
none of it right now except tighter type checking and relaxes syntax
allowances.

CAlive will eventually support a 100% native implementation of C90
and C99 with -c90 and -c99 switches, and I may simply create a C90
and C99 database which doesn't require the switches, and allows for
_c90 and _c99 blocks to be used within.

Providing that support is not my first goal, but everything about
the design is being coded with that end goal in mind. My current
target timeframe for supporting those features in around 2021.
-----[ End ]-----

Somebody else replied that it makes no sense for me to need a C++
compiler to compile CAlive, because if CAlive is less than C++,
then by definition C++ is greater than CAlive because it contains
the full subset of its abilities.

While that is not true because CAlive adds many new things I have
not seen in any other language, even the C/C++ components it does
have are not the issue.

My goal with CAlive is to eventually have it boostrap itself, so
I am writing code that is close to C with some C++ extensions.
In addition, the framework I'm writing the compiler in (called RDC)
is of such a design that all of the LibSF languages created in RDC
will be able to have a certain range of debugging abilities that
make it desirable for developers. In fact, my goal is to have the
best developer and debugger environment of any language, and to do
so at the C/C++ level, though with RDC it will be down to anything
that can be compiled into machine code level, including assembly.

-----[ Begin ]-----
Everyone can use C++. Nobody has to use CAlive. You are free to
compare them side-by-side and choose the compiler you want. You're
free to not even consider CAlive for anything. Nobody's forcing you
to use it or consider it. However, it will be (James 4:15 "Lord
willing") be a tool available to you at some point.

Per my vision: For performance and speed, you'll want a more mature
compiler (at least in the beginning). But for ease of development,
you will not find a faster development system than RDC, and subsequently
CAlive and other languages being written in RDC. In fact, if you have
the right developer code installed, you'll even be able to tweak the
compiler while you're compiling a program program, to literally step
through the compilation process and find out where it's failing and fix
the error, or to rewrite your code when you see why it's being
interpreted that way. You can also add new features on-the-fly, test
them in the debugger, be able to debug both the source code to be
compiled, and the way in which they are compiled.
-----[ End ]-----

My goals with CAlive are to honor God with the skills He first gave
me, and to give you a powerful tool for software development. I
would welcome your help in moving forward in this way. Please feel
free to contact me if you are interested.

The CAlive Google Group:
https://groups.google.com/forum/#!forum/caliveprogramminglanguage

Thank you,
Rick C. Hodgin