aartaka
commented
1 month ago Hello darinsecurity,
BF-ES
Brainfuck Enterprise Solutions trademark abbreviation is BES. Please use that to avoid miscommunication.
I think this project is incredibly fun and actually educational to break down what an operating system is. I am already running OS.BF on a custom-made interpreter for embedded boards. One day, I will create a special hardware board built specifically and effectively for running the Brainfuck interpreter at incredibly low power draw.
That is inspiring and I cannot wait to see that!
However, I've encountered an issue with the operating system where the file system functions more as a stack than a file directory. Multiple files can be created with the same name, but printing the contents of that name results in the most recently created file.
Yes, this is by design. OS.bf does not stand in the way of the user and allows them to create multiple files with the same name if they wish to. This might seem strange from the perspective of "classic" operating systems, but OS.bf is no regular OS, it's exploring the ways OS can look like in the future. No need for baggage of the past here.
Here are some features (in the context of this project) that I think would be pretty important:
- System information (clock, sleep). How many operations per second? How to sleep or delay for a certain amount of time?
Sleeping is definitely possible by buzy-loading the interpreter. There was no feature request for that yet, that's why it's not yet implemented. I've added it to the to-do list (eeacb684bfe04dce555dd4eadb8244fecfbe4a3d) of the project already, so that it's trackable.
* **External output channels** other than the default stdin/stdout interface (storage, network, etc.).
Brainfuck is minimalist and focused. There's nothing preventing you from using network or binary storage as input/output. Much like byte-by-byte input mode in Brainfuck ERC20 token
* **A standard for BF interpreter performance** (BMIPS) as employed in measuring the efficacy of BP interpreters, including JIT.
There are existing and well-established benchmarks that might serve as measurement device. This area remains to be explored by BES.
* **Creation of a standardized BF machine**, which includes standards for: * Bit size (8-bit) * Cell initialization (zeroes) * Wrap-around logic * Memory size (32,768 bytes) * Extended memory capability for server applications * Operations per second (and JIT capability)
Standardizing the implementation requirements for implementations BES software runs on is one of the priorities indeed. For now, most of BES products specify these parameters (alongside memory layouts) and there's no urgent need for that standard yet. Thanks for mentioning that—this is a priority now!
This is known as the BFSM, which is meant to support all BF-ES software by default. Inferring memory size from the system, and generally a construct for inferring system information would be useful. For instance, it would be beneficial if a BF interpreter could start virtual instances (processes) that are capable of requesting and using memory.
I'm afraid this is beyond scope of BES—we're interested in using the most reliable (vanilla) Brainfuck stack without getting into the dangerous area of custom implementations. This makes our code portable and dependable. In case you're interested in extending Brainfuck, look at dialects available at esolangs.org and use them whenever you consider it right.
Additionally, effective utilization requires a suitable BFSM capable of:
- Simplifying zero operations and additive shifting operations.
Mandating optimizations is beyond the efforts of BES too. There are endorced implementations (like Sade and Reb) that do optimizations, though.
Unfortunately, for one of the main features, system information, this may require an additional instruction or capability beyond that of the BF language.
This is intriguing, but, as I've said, we're sticking to the minimalist necessary basis of computing as the most reliable part of our products. We all appreciate your suggestions, though!
Best of luck,
Artyom Bologov CTO Brainfuck Enterprise Solutions One step ahead of the future
I think this project is incredibly fun and actually educational to break down what an operating system is. I am already running OS.BF on a custom-made interpreter for embedded boards. One day, I will create a special hardware board built specifically and effectively for running the Brainfuck interpreter at incredibly low power draw.
However, I've encountered an issue with the operating system where the file system functions more as a stack than a file directory. Multiple files can be created with the same name, but printing the contents of that name results in the most recently created file.
Here is an example:
As you see, multiple files with the same name can exist and can be printed. There should only be one file with the same name.
I am developing a JIT BF optimizing interpreter with branch prediction, multi-core processing, etc., and I find this to be an excellent start.
Here are some features (in the context of this project) that I think would be pretty important:
This is known as the BFSM, which is meant to support all BF-ES software by default. Inferring memory size from the system, and generally a construct for inferring system information would be useful. For instance, it would be beneficial if a BF interpreter could start virtual instances (processes) that are capable of requesting and using memory.
Additionally, effective utilization requires a suitable BFSM capable of:
Therefore, the establishment of a speed standard, BMIPS, should be used to measure the performance of BF systems beyond just operations per second.
Unfortunately, for one of the main features, system information, this may require an additional instruction or capability beyond that of the BF language. However, this is a promising start.