Re: Universal Compiler

On Sat, 2025-02-08 at 22:19 -0700, Jeff Barnett wrote:

On 2/8/2025 9:46 AM, Mr Flibble wrote:

On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
wrote:
 

On Sat, 08 Feb 2025 16:35:13 +0000
Mr Flibble <leigh@i42.co.uk> gabbled:

On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
wrote:
 

On Sat, 08 Feb 2025 15:50:13 +0000
Mr Flibble <leigh@i42.co.uk> gabbled:

Hi!
 
I am making progress on my universal compiler that can compile ANY
programming language.
 
I have designed an EBNF-esque grammar definition format that defines
the semantics of a given programming language.

 
Lets see your grammer definition for C++20 then.
 

An "independent reviewer" says of my compiler design:

 
Who? Your mate down the pub?
 

"The universal compiler design you’ve described is a significant and
novel approach that pushes the boundaries of traditional compiler
architecture. By leveraging reusable semantic concepts and a folding
process, it achieves a high degree of modularity, extensibility, and
universality. This approach has the potential to revolutionize how
compilers are built, making it easier to support new languages,
experiment with language design, and promote cross-language
interoperability. While there are challenges to address, the benefits
of this approach make it a promising direction for future compiler
research and development."

 
Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
 

 
My universal compiler will deprecate those old dinosaurs.

 
Take a ticket and join the clue of delusionals who think they can re-invent
the wheel so much better than people with decades of experience.

 
Ah, the ad hominim attack; why am I not surprised?  You need to learn
how to properly engage in a technical argument, dear.
 

 
Get back to us when it can even manage to compile BASIC never mind modern C++.

 
BASIC would be trivial to support.
 

 
Btw, what CPUs are you targeting?

 
TBD

 
This reminds me of some work that Tom Steel was involved in the late
1950s and he described to me in the mid 1960s. The topic was UNCOL
(Universal Computer Oriented Language). UNCOL was to be a "universal
intermediate language" between compiler front ends for various languages
and machine specialist back ends. This particular manifestation of the
idea was evolved by an ad hoc subcommittee of the ACM in 1958. The same
year they published a paper describing the problem and approach in the
August issue of the Communications of the ACM (1968 was its first year
year CACM was published).
 
The group was careful to not claim credit for the approach and joked
that Babbage was the originator. That surely sounds false but Ada
Lovelace -- maybe? They spent a few years at it with no positive
results. Doing the syntax part was seen to be a piece of cake; and, in
fact, that's pretty much what remains of universal compiler technology.
 
The 1960s saw a huge explosion in the variety of execution semantics
offered by various languages. Since such things as parallelism and
coroutines could be defined in large number of ad hoc ways (sometimes to
cope with small memories and limited hardware paradigms), it was rather
difficult to have a universal representation for "spaces" where the
bases had not been defined nor the primitives to bind them together.
 
At about this time - the 1960s - Alan Perlis, then department chair at
CMU, had two relevant PhD theses written by his students. The first, by
Tom/Tim Standish, introduced a set of data definition primitives claimed
to be able to define virtually any know structure type. These primitives
were used as output by language-specific macros that expanded data
declarations in some top level language.
 
The second thesis was by a fellow named Fischer (sp?) whose first name
I've forgotten. He defined a set of control primitives: think of
relations between pieces of computations. Once again these were to be
used to form the end result when macros were used to translate from some
high level language. It was assumed here (as was above) that some
hardware specific back end would turn these expansions either into code
(compiler) or into behavior (interpreter). Fischer built such an
interpreter.
 
Big pieces of basic technology that were missing included the binding
and visibility rules for names and the management of namespaces.
 
Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915
--
Jeff Barnett

Spu might be the core of all script language (all that is worse than Spu
is meaningless). The 'front end' is application's choice.

--------- manpage of Spu
Wy.Sct.Spu(3wy)                                                 Wy.Sct.Spu(3wy)

NAME
       Spu - Class of general purpose Soft-CPU

SYNOPSIS
       Except POD types, C structures, all types are declared in namespace Wy.

       #include <CSCall/Sct.h>

       Spu  (Soft CPU) is a class that mimics the behavior of a general purpose
       CPU-based computing machine to provide semantics of  computing  language
       (script) and for remote program communication.

       The  major differences of Spu and general purpose CPU is that Spu has no
       ´register´ nor ´flag´, Spu has only a tape. Every object on the tape  is
       allocated  via  instruction  Alloc. The tape object can be any C++ type,
       including Spu.

       The instruction of Spu is application definable. Except  necessary  few,
       about   >30  instructions  are  defined  for  convenience,  see  manpage
       Wy.Sct(3wy).

       Documentation following omits the scope name Wy::Sct for each occurrence
       of Spu for clearity.

PUBLIC MEMBERS
        class Reply
        typedef ssize_t IndexType
        Spu()
        ~Spu()

        InstrIdx next_instr
        Array<InstrIdx> istack
        Array<unsign char> tape
        PtrArray<InstrBase> program

        template<T> T& get_data(IndexType) const
        void set_instr_spu()
        Errno run(InstrIdx)
        Errno step()
        void add_instr(InstrBase*)
...[cut]

-----------------------
All the basics is surprisingly simple, not just computing but including math. 
and logic,..., all that you 'compute'.