Preprocessor output into Class processor

[Frederick Gotham]

I'm thinking of taking the output from the C preprocessor like this:

gcc -o compute.translation_unit -E -P compute.c

So then I'll have this translation unit and I'll run it through my own preprocessor, which will implement my previous code I shared about 2 weeks ago for doing polymorphism in C :

https://groups.google.com/forum/m/#!topic/comp.lang.c++/5lKrGQRQHQk

All my operators must be discernible from C operators, and so to invoke a method on an object, I might use syntax like:

object_name~>Method_Name(5, "dog");

(Note that that is a tilda instead of a hyphen, i.e. "~>" instead of "->", so it won't be confused with C's operator to access the members of a dereferenced pointer).

My preprocessor will turn this line into:

Virtcall(object_name,Method_Name)(5,"dog");

Construction and destruction of objects will be handled by simply declaring a class, perhaps with the 'class' keyword. I might also have a 'method' keyword like this:

class MyClass {
method void Constructor(int);
method void Destructor(void);
method void Some_Method(int, char const*);

int a;
double b;
void *p;
};

Similar to the old C style of always writing 'struct' or 'union' before a struct or union, you will always have to write 'class' before a class, and so you would create an object like this:

class MyClass obj(42);

And you would take a pointer in a function's parameter list like this:

void Some_Global_Func(class MyClass *p);

So if you put the following snippet through my preprocessor:

{
class MyClass obj(42);

obj~>Some_Method(5, "dog");
}

then it will come out as:

{
struct MyClass obj;
MyClass_Construct(&obj, 42);

Virtcall(&obj,Some_Method)(5,"dog");

Virtcall(&obj,Destructor)();
}

In order to be able to call the destructor at the right time, I think I'll use 'defer' which you can see on this page if you scroll down about half way:

https://mort.coffee/home/obscure-c-features/

So then I'll take the output of my own preprocessor and feed it back into the C compiler. The whole process will be something like:

gcc -o compute.preprocessed -E -P compute.c
gotham_preprocessor -o compute.translation_unit compute.preprocessed
gcc -o compute.o -c compute.translation_unit

So then you'll have an object file, "compute.o" which you can give forward into the linker.

So you might ask, what's the point in all this if we already have C++?
Well there are still loads of very small, very slow 8-bit microcontrollers with less than a megibyte of RAM/ROM that don't have a C++ compiler. My new preprocessor will make it a lot easier to port C++ code with polymorphic classes to C.

[Christian Gollwitzer]

Am 28.08.20 um 18:14 schrieb Frederick Gotham:

> I'm thinking of taking the output from the C preprocessor like this:
>
> gcc -o compute.translation_unit -E -P compute.c
>
> So then I'll have this translation unit and I'll run it through my own preprocessor, which will implement my previous code I shared about 2 weeks ago for doing polymorphism in C :
>

So you are replicating some of the functionality of Cfront.

Another way would be to compile C++ to C using an LLVM backend; there is
one at https://github.com/JuliaComputing/llvm-cbe

Christian

[David Brown]

On 28/08/2020 18:14, Frederick Gotham wrote:

> So you might ask, what's the point in all this if we already have
> C++?

> Well there are still loads of very small, very slow 8-bit
> microcontrollers with less than a megibyte of RAM/ROM that don't have
> a C++ compiler. My new preprocessor will make it a lot easier to port
> C++ code with polymorphic classes to C.
>

Code that is written in C++ with polymorphic classes will not be
suitable for such small microcontrollers in the first place. So there
is no benefit from an easier way to port the code - if the code in C++
is too demanding, then the whole code structure of the source is too
demanding for the target. Either the code needs re-written from scratch
in C, or the user needs a bigger microcontroller (there are 32-bit
devices for less than half a dollar - there are rarely good reasons for
starting new projects with brain-dead 8-bit CISC microcontrollers. The
prime reason for using them is to continue and expand on existing
designs, in which case software in a new language is out of the question).


And note that people use C++ on 8-bit devices already, if the device is
reasonably flexible (such as AVR's, rather than PIC's, 8051's, COP8's,
and that kind of device).

If you think your project will be fun, great.

[bol...@nuttyella.co.uk]

On Sat, 29 Aug 2020 19:24:16 +0200
David Brown <david...@hesbynett.no> wrote:
>devices for less than half a dollar - there are rarely good reasons for
>starting new projects with brain-dead 8-bit CISC microcontrollers. The

Power consumption in battery powered devices is a very good reason.

[David Brown]

No, it is not. These kind of badly outdated cpu architectures are
nowhere close to state of the art of low power consumption. A
Cortex-M0+ device (32-bit) will use much less power than a PIC or an
8051 for the same task.

[bol...@nuttyella.co.uk]

On Sun, 30 Aug 2020 21:59:12 +0200

David Brown <david...@hesbynett.no> wrote:
>On 30/08/2020 17:59, bol...@nuttyella.co.uk wrote:
>> On Sat, 29 Aug 2020 19:24:16 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> devices for less than half a dollar - there are rarely good reasons for
>>> starting new projects with brain-dead 8-bit CISC microcontrollers. The
>>
>> Power consumption in battery powered devices is a very good reason.
>>
>
>No, it is not. These kind of badly outdated cpu architectures are
>nowhere close to state of the art of low power consumption. A
>Cortex-M0+ device (32-bit) will use much less power than a PIC or an
>8051 for the same task.

Lets see some figures then because I find that very hard to believe
particularly if the PIC is operating in wake-on-interrupt mode.

[David Brown]

Look them up yourself - the details all depend on exactly what you want
the system to do. But here's a hint for you - the current consumption
of the core during the deepest sleep modes is almost completely
irrelevant in most battery powered devices.

Or if you want proper help with embedded design, find someone who is
willing to spoon-feed you and who also has more than your own "did a few
courses twenty years ago with a single microcontroller" experience.

Finding things "hard to believe" just because they are outside your own
experiences seems to be a pattern for you. It does not encourage others
to help you. You appear to be convinced that your very narrow and badly
outdated thoughts on embedded development are all there is to know of
the field - so there is little point in giving you advice or information.

If you wake up one day and realise that perhaps you don't know
everything, maybe you can ask some questions and learn something.

[bol...@nowhere.co.uk]

On Mon, 31 Aug 2020 11:33:57 +0200

Translation: "Err, sorry, I can't provide those figures but I'll will provide
a load of self righteous bluster in its place and hope you go away".

[David Brown]

I certainly could provide figures. I could point you to a Cortex-M4
microcontroller with 20 nA sleep modes. I could point you to designs
with code written in C++ that don't have batteries at all, but get
enough energy from the user walking around. But what does that help you
or anyone else?

[bol...@nowhere.co.uk]

On Mon, 31 Aug 2020 12:11:10 +0200
David Brown <david...@hesbynett.no> wrote:

>On 31/08/2020 11:37, bol...@nowhere.co.uk wrote:
>>> If you wake up one day and realise that perhaps you don't know
>>> everything, maybe you can ask some questions and learn something.
>>
>> Translation: "Err, sorry, I can't provide those figures but I'll will provide
>
>> a load of self righteous bluster in its place and hope you go away".
>>
>
>I certainly could provide figures. I could point you to a Cortex-M4
>microcontroller with 20 nA sleep modes. I could point you to designs

Yes, 20nA, very good. However not as good as these 8 bit PIC:

http://www.farnell.com/datasheets/1523199.pdf

"PIC microcontrollers with XLP technology feature the world’s lowest active an
d
sleep power consumption"

"Active currents down to 50 μA/MHz
Sleep current as low as 9 nA
Battery lifetime > 20 years"

Chew on that.

[David Brown]

On 31/08/2020 17:43, bol...@nowhere.co.uk wrote:
> On Mon, 31 Aug 2020 12:11:10 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 31/08/2020 11:37, bol...@nowhere.co.uk wrote:
>>>> If you wake up one day and realise that perhaps you don't know
>>>> everything, maybe you can ask some questions and learn something.
>>>
>>> Translation: "Err, sorry, I can't provide those figures but I'll will provide
>>
>>> a load of self righteous bluster in its place and hope you go away".
>>>
>>
>> I certainly could provide figures. I could point you to a Cortex-M4
>> microcontroller with 20 nA sleep modes. I could point you to designs
>
> Yes, 20nA, very good. However not as good as these 8 bit PIC:
>
> http://www.farnell.com/datasheets/1523199.pdf
>

> "PIC microcontrollers with XLP technology feature the world’s lowest active an
> d
> sleep power consumption"
>
> "Active currents down to 50 μA/MHz

> Sleep current as low as 9 nA
> Battery lifetime > 20 years"
>
> Chew on that.
>

You missed the bit where I pointed out how utterly useless these figures
are. If you knew the first thing about what you were doing, you'd
understand that already.

[bol...@nuttyella.co.uk]

On Mon, 31 Aug 2020 22:50:07 +0200

You really are a class act:
1) Make assertion, don't back it up.
2) Oh ok, you'll back it up with some figures under duress.
3) Assertion proven false.
4) Claim figures were rubbish anyway

You should go into politics.