XOJO uses pcode ?

[chrisc]

Hi

I heard from a reliable source that XOJO uses pcode? It is not really a true native compiler like
PureBasic. Has anyone investigated this matter ?

Appreciate your comments on this as I'm still deciding which language to convert
my PowerBasic code to.
Chris

[Shield]

The sites http://www.xojo.com/ and http://www.xojo.com/visualbasic/ are plastered
full with the buzzword "native".

Xojo apps are compiled to native code. They do not contain byte-code that is run by a virtual machine.

So I guess there is your answer if they are not completely trying to mislead everyone.

[chrisc]

They claimed it as native code, but my friend did a check on its assemblies and found that the compiler
transform the source to pcode and then overlay these pcode into an exe file. So it is not exactly a native
-- part of it is native the other part is pcode. That's perhaps the reason why XOJO do not compile
to dll but to only exe.

So it is unlike Purebasic which compile to entirely native exe and dll.

[TI-994A]

...it is not exactly a native -- part of it is native the other part is pcode. That's perhaps the reason why XOJO do not compile to dll but to only exe.

With today's plethora of high-performance, cross-platform compilers, building native binaries is not really a feat anymore. And Java and C# has shown that intermediate languages can be just as fast. However, not all languages generate highly-optimised, well-structured code, in a tight and fast bundle.

Most cross-platform RAD tools utilise a host of pre-built external libraries that get bundled with the final executables, resulting in bloated, low-performance binaries. In the case of Xojo, a typical Hello World application weighs in at a whopping 5MB, while PureBasic does the same thing with a single, independent 5KB executable; no additional runtimes, frameworks, dependencies, or virtual machines.

Xojo also has a reputation of generating sluggish executables. Here again, PureBasic is a performance powerhouse, producing fast and efficient standalone binaries, comparable even to mainstream compilers. Java requires their virtual machines to be installed in order to run their apps, and C# is dead in the water without the dot net framework.

All in all, there's been nothing quite like PureBasic. A class of its own.

[Shield]

They claimed it as native code, but my friend did a check on its assemblies and found that the compiler
transform the source to pcode and then overlay these pcode into an exe file.

Any chance of getting an exe produced by Xojo? I'd like to have a look just out of curiosity.

PureBasic is a performance powerhouse, producing fast and efficient standalone binaries,
comparable even to mainstream compilers.

After many, many years of using PB, this statement might not quite be accurate.

All in all, there's been nothing quite like PureBasic. A class of its own.

With this, however, I completely agree.

[Keya]

only need to look in a debugger to find out, no need to speculate or spread rumors about somebodys hard work! so lets do that ...

I opened up a simple console example, basically a Hello World, and added: "Dim myint As Integer" and "myint = myint + 3", and stdout'd that to protect against potential garbage collection. Xojo wont let you 'Build' a compiled exe without getting a license, but it does let you run a Debug version - which is a compiled exe anyway, so i made a copy of that (864,009 bytes). To be fair I don't know how much of that 864kb is added debug material (like PB's Debug-mode exes).

I then changed "myint + 3" to "myint - 3", changing add to sub, and recompiled. Hex editor confirmed only 1 byte has changed (which also confirms Xojo isnt correctly updating the PE header checksum hehe). So I attached in a debugger and sure enough the byte that had changed was x86 "2BC1 sub eax,ecx" <> "03C1 add eax,ecx".

So yes, Xojo is compiling to native code at least in this brief test.

When I ran it on XP it did nothing - it ran, and stayed resident in memory, but did nothing, kinda like a PB console app like this "Repeat: Inkey(): Forever". The IDE wouldnt let me install on XP either, so i used Win7. When I ran the exe from the command prompt on Win7 i was greeted with "Failed to locate Framework DLL", but running it from within the IDE was ok.

Another thing worth noting is that this framework is in the form of a runtime library XojoConsoleFramework32, which is 29 megabytes. (Visual Basic 6's MSVBVM60.DLL for comparison is 1.3MB). The GUI framework is pretty much the same size so I can't help but wonder if there's a lot of overlap between the console and GUI frameworks (if i had to give frameworks id rather just give someone a single 35mb framework than two overlapping 30mb ones).

So, Xojo in conclusion - native exe: Yes (speed/size/quality unknown). Large (30mb) runtime framework also required for Hello World: Yes. And chrisc, it's disappointing that your "reliable source" is spreading untrue rumours about somebodys hard work simply because they didn't bother or are unable to validate for themselves.

Code: Select all

12/08/2016  08:28 PM        29,208,544 XojoConsoleFramework32.dll
12/08/2016  08:28 PM        38,781,716 XojoConsoleFramework32.so
12/08/2016  08:28 PM        30,352,352 XojoConsoleFramework64.dll
12/08/2016  08:28 PM        36,418,712 XojoConsoleFramework64.so
12/08/2016  08:28 PM        33,538,011 XojoConsoleFrameworkARM.so
12/08/2016  08:28 PM        29,855,200 XojoGUIFramework32.dll
12/08/2016  08:28 PM        38,673,816 XojoGUIFramework32.so
12/08/2016  08:28 PM        31,152,608 XojoGUIFramework64.dll
12/08/2016  08:29 PM        35,763,912 XojoGUIFramework64.so
12/08/2016  08:29 PM        33,309,294 XojoGUIFrameworkARM.so

btw does anyone know why VB6 offered both PCode and Native compiles!? seems strange to offer a PCode if youre offering a Native, i must be missing something

[Fred]

pcode (if correctly done) allows more optimisation depending of the running target processor: you can ship a single exe which will run on x86 or x64, use SSE/SSE2 or any other hardware stuff if available.

[Keya]

ahh! JITish kinda gig. I think i prefer being able to query !cpuid myself though and branch off to different functions that way

[Shield]

And how often do you actually do that?
PB comes with such an option but nobody ever used it.

What Fred meant, though, is being able to run the same file on different architectures.
With .NET or Java, for example, I can create an executable on Windows x86, copy the file
to Linux x64 and run it on Linux without any modification.

The main advantage with JITs, in my opinion, is that they are able to optimize
code execution on a specific platform *at runtime* using statistics.

[Keya]

And how often do you actually do that?

how often do i use !cpuid?? well i wouldn't say my use of it is uncommon, ive got over 70 personal .pb/.pbi files that use it, and i'm enjoying learning inline asm with PB. I mainly use it to check for CRC instruction, AES instruction, level of SSE support, RdRand instruction, AMD vs Intel etc, or just to use its serializing nature which you want before rdtsc etc. Although, no i dont check for MMX hehe YOU WANNA RUN MY APPS YOU GET A CPU WITH MMX, ITS 2016! or 17 or something

PB comes with such an option but nobody ever used it.

It's not used because it's actually a non-option; I don't know why it's included because selecting "MMX", "SSE" etc in PB compiler makes no changes to the exe. It seems like it's a long-time placeholder for a future feature.

[Shield]

It's because the PB libs do not include separate functions for different architectures.
The functionality is there, i.e. you could write a PB library in C that provides different functions
and PB will select the correct one, but I have never seen anyone do that in my 15 (?) years of using PB.

[Keya]

Ahh, so it does do something! hehe. yes i hadnt thought about using different libs with -mmx etc passed via cmdline, groovy. im really enjoying being able to call libs from PB, talk about doors opening

[chrisc]

Thank you, be it native or otherwise XOJO runtimes framework is so huge, it is at a
disadvantage when compare to PB

I don't think I would be using it. It would be similar to using C# with the bloated
.Net framework.

[Tenaja]

Most cross-platform RAD tools utilise a host of pre-built external libraries that get bundled with the final executables, resulting in bloated, low-performance binaries. In the case of Xojo, a typical Hello World application weighs in at a whopping 5MB, while PureBasic does the same thing with a single, independent 5KB executable; no additional runtimes, frameworks, dependencies, or virtual machines.

As developers, we know this makes PB better. Unfortunately, many users are ignorant people who think "more is better", and if they see two programs to choose from, one takes no ram, and the other requires 5MB, the latter must have more special features or benefits that aren't listed.

[Tenaja]

pcode (if correctly done) allows more optimisation depending of the running target processor: you can ship a single exe which will run on x86 or x64, use SSE/SSE2 or any other hardware stuff if available.

Java is a perfect example of "correctly done". It is faster than many "true compiled" languages, and only a bit slower than C.