PBXB V14 for Testing

Started by Theo Gottwald, July 07, 2026, 06:09:34 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Theo Gottwald

I am giving the current V14 for download.
Its not the hoped final version, yet I hope it to be good enough to be usable.
I may need to make a break from the project for some days to some weeks.

Anyway the updates will come faster then in earlier times, check this version and find out if you can do something with it. The german help file is included.

Post your comments, what you like or not like below this post.

PBXB V14


Raymond Leech

The zip file that downloaded is pbxb64_v12.zip
The command "pbxb64 --version" shows
QuotePBXB64 version 0.50.0-V12

I think your build/package process is still not working right (see previous comment on _v13)

  •  

Raymond Leech

#2
I was able to download manually using this link
https://smart-ai-robot.com/compilers/pbxb64/download/PBXB64_V14.zip

It also looks like the English help file is now in German too.
  •  

Theo Gottwald

ok, i was told the download should work now.
Do some tests and report me if it generally works.

Raymond Leech

Theo, will you be releasing the v14 help file in English?
  •  

Theo Gottwald

#5

Raymond Leech

@Theo Gottwald

The results of my testing have been pretty good but I've found another problem. The sizeof and len functions return different results between PB and PBXB64.

#COMPILE EXE
#stack 4194304
#DIM ALL
type zudt
 zptr1 as byte ptr
 zptr2 as quad
end type
SUB test_strptr()

  ' Local storage
  local i as word
  local ptr1 as byte ptr
  local ptr2 as quad
  local myudt as zudt
  local itext as string
  local text2 as string*20

'------------------------------------------------------------------
program_begin:
  itext = "3f7a059b65d6cb0249204aac10b9f1a4ac9e5868adebbe935a9eb5b9019e1c938bfc4e5c5378997a3947f2"
  print "var: sizeof, len"
  print "i: " + str$(sizeof(i)) + ", " + str$(len(i))
  print "ptr1: " + str$(sizeof(ptr1)) + ", " + str$(len(ptr1))
  print "ptr2: " + str$(sizeof(ptr2)) + ", " + str$(len(ptr2))
  print "zudt: " + str$(sizeof(myudt)) + ", " + str$(len(myudt))
  print "itext: " + format$(sizeof(itext), "#,") + ", " + str$(len(itext))
  print "text2: " + format$(sizeof(text2), "#,") + ", " + str$(len(text2))
  print ""
END SUB

'------------------------------------------------------------------

'------------------------------------------------------------------
FUNCTION PBMAIN()
    CALL test_strptr()
END FUNCTION
'******************************************************************

PowerBASIC returns:
var: sizeof, len
i:  2,  2
ptr1:  4,  4
ptr2:  8,  8
zudt:  12,  12
itext: 4,  86
text2: 20,  20

While PBXB64 returns:
var: sizeof, len
i: 8, 0
ptr1: 8, 0
ptr2: 8, 0
zudt: 8, 0
itext: 8, 86
text2: 8, 0

It looks like PBXB64 is returning the sizeof the pointer, not the size of the object. Len is returning zero unless it is a string.

  •  

Raymond Leech

Second problem.
Using the above example, if you replace the line
print "i: " + str$(sizeof(i)) + ", " + str$(len(i))with
print "i: " + trim$(sizeof(i)) + ", " + str$(len(i))
PBCC returns
i: 2,  2
While PBXB64 returns
i: , 0
In PB, trim$ functions similar to ltrim$(str$(numvar)). I remember a discussion in the old forum that trim$ was the faster method, so I used it extensively.

  •  

Theo Gottwald

At this time, i recommend that you help your self and make own implementations of these commands that overide the builtin commands.

Use the #OVERRIDE directive to impplement your own version of the command and overrride the builtin versions. Thats why its in there. You can override all builtin commands with own version.

Due to the fact that - as we know - "Compiler building" is not a bussines but a fun-sport, i will not be able to give you something better possibly this month. Its a question of time and resouces and boiling it down, a question of money. So lets be patient and hope for free resources next month.

Raymond Leech

@Theo Gottwald
QuoteUse the #OVERRIDE directive to implement your own version of the command

I think you misunderstood my intentions. As I stated before, I have thousands of code snippets, low-level routines, etc. My purpose was to help you validate some edge cases such that you would use the feedback to help your models be more precise. For example, the trim$(integer) worked in one of the previous versions, but doesn't work in v14.

I also may have misunderstood your purpose. I assumed you were trying to make a compiler that was fully PB compatible (along with the the other languages). If your path is to exercise the AI models to get 'close enough' on each of the languages, I see where my reports would be both unhelpful and distracting at this stage in your endeavor.

I'll continue to monitor your progress, as I find it fascinating that you've produced so much in such a short time!

Theo Gottwald

#10
@Raymond Leech What you can tell me currently is:
a) what features you like
b) What works fine
c) Things you found work and are useful and were missing in PB
d) Things that are missing to get implementation round
This stuff is useful as i can then check it will be implemented in future versions.

Bug reports do not help me as it is by now.
As a progammer you might think "A he may like a bug report". Because generally a bug report is a good thing.
Here the situation is different.
At the curent moment this will not help me because due to situation of the PBXB64 Source-code as it is, any bug report is from "a very outdated position".

The point is, we had a degradation in PBXB64 at a time shortly before it had a very good state and there was no timely backup. We lost 25% of the Soucecode it degrraded from 11 MB to 7 MB.
It can happen - we will get over it.

Once there is a new version we will have to start over at many places.
Things that worked before may be quite different, new features will be there and also old may be missing.
I will tell you when bug reports make sense again, typically in the first few days after a new release.
While it might be called V15 is not really a successor to V14 but a successor to V7 or such (whatever was the last Backup beforer the degradation).

Meanwhile i hope PBXC64 as the most modern concept may also get more usable, but anyway - from what i have heared PBXA32 also went forward a lot and even seems also to have LINUX Backend so things are progressing at multiple places.

So long i hope you have fun with PBXB64 and as said tel me what you like and also tell me if you suggest any other implmentations for whatever features. It will take a while to get it back wherer it was.

2026-07-12 20_30_16-Greenshot.png

Theo Gottwald

#11
Greetings from PBXB64 ... its in recovery.

UDT's may contain STRINGs and als STRING-ARRAYS and also other UDT's to any depth.

REDIM PRESERVE must work correctly on ANY of these and also on the lower and upper BOUND.
I had so many Problems with this in the original PB so we will take care of that.

2026-07-14 11_44_21-Greenshot.png

Raymond Leech

@Theo Gottwald
QuoteWhat you can tell me currently is:
d) Things that are missing to get implementation round

I wonder if a more powerful RegEX engine might be useful. Something like PCRE2, or the Chrome/Edge engine (Irregexp)?

To maintain compatibility, I'd steal the additional syntax needed for regexpr/regrepl from the open statement. That way, the original PB engine compatibility could be maintained while adding the expanded capability.

For example the open statements supports ansi or wide mode via
OPEN filespec [FOR mode] [ACCESS access] [LOCK lock] AS
  • filenum& [LEN = record_size] [BASE = base] [CHR = ANSI|WIDE]

You might extend the syntax such that the original syntax relies on the PB compatible engine:
QuoteREGEXPR mask$ IN target$ [AT start&] TO iPos& [, iLen&]

And the engine=xxx extension indicates the additional engine(s) supported by your compiler
QuoteREGEXPR mask$ IN target$ [AT start&] TO iPos& [, iLen&] ENGINE=[PCRE2 | Irregexp | etc]



  •  

Theo Gottwald

#13
@Raymond Leech That is definitey planned. I do generally not copy limitations from PB, so if we do RegEx we will make it complete.
But without external libraries, all homemade as always.

Theo Gottwald

Recovery is ongoing.

2026-07-18 16_58_47-Greenshot.png