|
Post by rosy on Dec 13, 2021 11:36:24 GMT -6
I asked why there is no normal copiler, answer - compatibility. I don't know what for, because you have to build each platform separately anyway. For me, this compatibility looks like this, that I have to make several versions of the program. In 3.13 for Android, in newer for www. I had to rewrite all the programs, because several functions work differently in the new version (e.g. today I discovered a change in REPLACE, the old function changed its operation, and in its place a new one was created, which works like the old one - it's absurd). Here are my web games:
Probably only PONGY works properly ... It is also interesting that the keyboard in these games reacts only after some time after being uploaded to the itch.io server.
|
|
|
Post by n00b on Dec 13, 2021 17:50:48 GMT -6
Compatibility in this case would mean across different platforms with the same runtime. RCBasic compiles to *.cbc files which are run by a runtime executable.
This means you do only have to build your RCBasic program once if you wanted to manually copy and paste the *.cbc file, all your project files, and the runtime binaries for each platform. The build tool just automates that so you don't have to do all of that manually.
|
|
|
Post by rosy on Dec 13, 2021 18:29:03 GMT -6
Whether manually or automatically, I have to do something, it is not enough to copy it. I can also transfer the source code. And this compatibility is not there anyway.
|
|
|
Post by n00b on Dec 14, 2021 8:31:53 GMT -6
I am not sure what you mean. You are able to compile your code once and run it on all supported platforms.
The distribution tool does not rebuild your code for each platform. It just automates bundling your compiled code with the runtime for each platform. Its the same *.cbc file being bundled with each one.
A few years back, I included instructions on how to setup projects in android studio, how to setup your projects on each platform to bundle, how to setup a toolchain to rebuild the runtime for various platforms, etc. Many people had trouble with this so I included the distribution tool to make it easy for anyone to ship the projects on the platforms they wanted.
I even went a step further on linux and bundled the AppImage Kit with the linux version so you could just build a stand-alone AppImage Container for your project. Its not perfect and is constantly being improved but the distribution tool is written in RCBasic and all the source code is included which means you can modify it to meet your needs.
Look at these files: app_build_gui.bas - The GUI for the distribution tool pkg.bas - The command-line backend for the distribution tool
Those 2 files are the main files that make the tool work.
|
|
|
Post by rosy on Dec 14, 2021 8:54:42 GMT -6
I know how it works, I don't know what it gives me. All you need is compatibility at the source code level. I see no problem compiling on all platforms. The package must be built separately anyway.
|
|
|
Post by n00b on Dec 14, 2021 9:44:06 GMT -6
I know how it works, I don't know what it gives me. All you need is compatibility at the source code level. I see no problem compiling on all platforms. The package must be built separately anyway. The runtime approach is much more suited to RCBasic. Most of the users here ( me included ) don't want to troubleshoot errors with GCC/XCode/Clang/NDK/etc. With the distribution tool, you don't have to worry about issues with linkers or compilers because I do all of that before hand. You have something that is faster than a interpreter but less complex than C++.
|
|
|
Post by rosy on Dec 14, 2021 10:03:09 GMT -6
And are you able to briefly describe how this bytecode works? Because I also do not understand why it is faster than the interpreter.
|
|
|
Post by aurel on Dec 14, 2021 11:34:44 GMT -6
Because I also do not understand why it is faster than the interpreter.
because you never compare it with bechmark bytecode is in most cases just array of integers operations with integers are fast most of byte-code interpreter use some sort of virtual-machine which interpret that byte-code
|
|
|
Post by n00b on Dec 14, 2021 18:56:17 GMT -6
And are you able to briefly describe how this bytecode works? Because I also do not understand why it is faster than the interpreter. To add on to what aurel said, reading a bunch of integers at runtime also allows the runtime to skip the parsing process since the compiler takes care of that.
|
|
|
Post by rosy on Dec 17, 2021 14:51:19 GMT -6
Or maybe someone will explain to me why the programs have to be compiled separately in different versions of Linux? How are these distributions different?
|
|
|
Post by n00b on Dec 17, 2021 16:02:29 GMT -6
I will try to give a decent explanation on all of this. Here is a rough idea of how the runtime works. The compiler takes your BASIC program and converts it to an assembly language that I made up. Look at this line: print 5 + 7 The compiler would convert this to something that looks like this: 'These lines will store the numbers into the VM number registers mov n0, 5 mov n1, 7
'This line will do the math and store the result in n0 add n0, n1
'Finally this line will output the number print n0 When it is done we would have the following RC assembly code: mov n0, 5 mov n1, 7 add n0, n1 print n0 Next the compiler will take that assembly code and convert it to byte code ( integers ). You can check out the VM assembler instructions here VM Instructions to see what integers these instructions are converted to. In this case the mov instruction will become 33 since we are moving a raw number into a number register. So mov n0, 5 becomes these 3 integers Instruction | Register number
| Raw Number Value
| 33 | 0 | 5 |
I won't go over all of these instructions here but you can look at that documentation if you are really interested. Once the compiler finishes generating the bytecode for every instruction it will write it out to a *.cbc file (compiled BASIC code) When you run a *.cbc file with the RCBasic runtime and it sees the number 33, it knows the next 2 values will be a number register and a raw number value. It will set the corresponding register to that number value and move on to read the next instruction. Now to answer your question on different linux versions, there is actually only 2 ( a 32-bit and 64-bit ). There are multiple ways of packaging the 64-bit version, either as an AppImage or standard distribution but the binary that is being packaged is the same.
|
|
|
Post by rosy on Dec 18, 2021 12:28:14 GMT -6
So I can download, for example, the latest Firefox and it will work in any Linux?
|
|
|
Post by n00b on Dec 18, 2021 20:20:47 GMT -6
So I can download, for example, the latest Firefox and it will work in any Linux? It depends on how it is packaged but yes, a 64-bit linux binary should work on any 64-bit linux system and a 32-bit linux binary should work on any 32-bit linux system.
|
|
|
Post by rosy on Dec 19, 2021 10:16:46 GMT -6
Then why are there different packages on different distributions? Why, for example, this: aranym.github.io/download.htmlI had to compile from source when I changed the version of the system (of the same system) because it didn't want to work after copying?
|
|
|
Post by n00b on Dec 19, 2021 11:59:48 GMT -6
rosy Like I said before, packaging is everything. This isn't a simple subject to explain but I will try. Linux distributions come with a bunch of software bundled with them. Some of this software are not executables but a compiled code that is just meant to be referenced by executables. This compiled code is called a shared object. When a program is compiled it references code in these shared objects. You could take the compiled binary and run it on another system as long as it also has these shared objects. But there are generally different versions of these shared objects on different systems. A good example of this is glibc, the C standard library. These different versions of libraries are often incompatible with other versions of the same library. Also, most linux distro's include different libraries by default and don't have the same libraries in there repos. This is why I said that packaging is everything. Linux does support self contained software that includes the versions of libraries that they were used to build the software. The big 3 containters are FlatPak, Snap, and AppImage. There are differences between them but they all basically do the same thing. If you are using a DEB file or an RPM to install the software you will need to be on a system that has a package manager that can handle those types of packages. You could get a DEB, RPM, or whatever package you download to work on a unsupported system if you want to extract the files from the package and track down the libraries it expects but that is much more complex than your average linux user would probably be capable of. This was a very brief explanation of this and I would suggest looking into a more credible source than me. I am not really an expert on any of this.
|
|