Site update at: https://smart-ai-robot.com showing futurer compilers

[Theo Gottwald]

I have uploaded a Site that already contains the parts that will ne taken by future compilers.
While the compilers are still under tests, debugging and construction, the help files can already be downloaded.

Jürgen told me that his compiler did not get a lot of interest so he will delay his project until direction October. So i will publish mine earlier.

https://smart-ai-robot.com/

[Raymond Leech]

Theo, I've looked and cannot find what differentiates your compilers.

For 64bit, you have pbxa64, pbxb64 and compiler64 (similar for 32bit).

Are these different experiments on writing a compiler?

Are they "language-equivalent"? In other words, all support the same BASIC language syntax, just created by using different toolsets?

[Theo Gottwald]

@Raymond Leech Then we have both the same problem.
If it wouldn't be like that i would stop the development of all but one best compiler.

So i don't know and hope people will help me with comments on this topic.
YES, they are KI-Developments with different ... methods.

And while i originally prefered CompillerX32 and CompilerX64,
it turned out that they are far behind and PBXA32 and PBXA64 took the lead.

But then surprise PBXB64 took the lead again today.
So i just let it run and wait and will se which one is really usable first.

BY today PBXB64 should be mostly Bug-Free with amazing feature - BUT does not include the full PB Commandset.
PBXA64 has nearly the full commandset but is not bug-free ... thats the game until there is a clear winner.


The system is the same like in old germany when they build the old "New Reichskanzlei".
They did not take one company to do it  - like they do today -
but 2 companies and they were "building against each other".

So as a result in opposition to how its today the building was even ready before the planned time and it was cheaper then planned.

So i founded "Compiler Workshop" and now have several compilers in the Que, 3 C-based, 2 - in PB, and 1 in ASM.
And what i do is a bit directing, and a lot of watching, waiting,  and seeing what happens.

Today i went on the WEB-Site to see the progress, - just like you -
and i saw that PBXB64 took the lead and has amazing features we never dreamed from in old days of Powerbasic.
See below.
So from today i would say TRY PBXB64. This can change in a few days.

I instructed them to implement Stan's HLIB-Datatypes and this is a part of the results.
Now imagine that you can use all of these Datatypes also as Parameters in Functions and even to return results. This is far above what we could do easily with Powerbasic. Also the UDT's possibly can also contain other UDT's and also container-Datatypes.

And we are just starting.

[Raymond Leech]

Theo, thank you for the explanation. While I might not completely understand your process, you've given me a better idea about what you're trying to accomplish.

Following are my "opinions" and are not intended to influence your focus or development.

My interest lies in a compiler that is the most syntactically equivalent to the existing PB compilers. I have a huge codebase across several packages. Although the applications run completely fine in 32bit, I'm always interested in 64bit offerings. My interest is always constrained by the conversion effort required. In other words, if the conversion were significant enough, I might just rewrite it in something else (like C# for example). 

You and Juergen seem to have the most syntactically compatible compilers. Unfortunately, Juergen omitted the binary option of the join$ function, which made it a non-starter for now.

I wish you both success in your efforts and will continue to follow your progress.

[Theo Gottwald]

@Raymond Leech I always use the BINARY Option in my programs, so you can be sure that we also support it in ALLL Compilers.

Also in PB there was a problem, if the Array you Parse$ the Strings in was not dimensioned properly using Parsecount, it would crash.

We will do that automatically IF the dimensions of the Array are not sufficient, we will do that. No crash.

About Jürgen, for you Jürgens compiler would be ok, and i guess he will add that option of you tell him you need it.
But not before October if i got him right.

On the other side you can also try my compilers and see where they are going.
And keep me updated on your findings, i will watch to have them fixed in short time < 1 week.

Besides we are in the same situation, i also have a lot of PB code and thats why i do that.
Thats also why i released the compilers early ->after i heared that Jürgen will not do that.<-

If Jürgen had released i would not release now but when they are bugfree. But its like it is.
I want those like me and you show that we really have something in the oven, that is still baking - but its there.
No need to change to other languages because of that.

But even IF you want to change to C, my compilers will make it easy for you as they have a c-frontend also.
And this will also be developped to a complete C-79 frontend.

Did you try PBXB64 the newest release?

[Stan Duraham]

I tried the wrong version. I can see some things compiling and working on PBXB64. The only advice I can give is Occam's razor, take the simplest path and add complexity later. Looking forward to your progression.

[Theo Gottwald]

@Stan Duraham The basic rules of developement are rapidly changing, Stan.
For humans your rules are important because of human limitations.

For an KI its not a larger problem either to develop something simple or something complex if both have the same effective size in the contextspace. Thats hard to understand but try it - chat GPT takes the same time for intelligent or stupid questions within some range.

It boils down to just another mathematical formula of the same length.
So the point is to find the perfect complexity for the next steps - not to try to waste the tokens with "human-ranged results".

The backend about testing is another question.

If you take a look on the current design with several frontends in each compiler,
you see we have never tried "to make a small 5-commands compiler that already worked".

In fact i believed Jürgen would relelase his compiler first and i would mine direction October.

Now its like this but it stays interesting because we get new updates nearly every day with a lot of bugfixes at least for the PBXA64 and PBXB64. These 2 are no on top of the Prio-List.

And there is not way both will make your HLIB-native compiler datatypes.
Maybe after that at least those PB'er will really understand their real value with time.