Multiple files can exist with the same name

[darinsecurity]

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:

os.bf version 0.32.0-beta-8

Copyright (C) 2023 Artyom Bologov
Copyright (C) 2023-present Brainfuck Enterprise Solutions Ltd.

os.bf is provided as is, with absolutely no warranty, under the terms
of WTFPL+PATENTS license. See the SOURCE-LICENSE, PATENTS, and
TERMS-OF-SERVICE (for commercial use) for more information.
l
s file_a one
l
file_a
p file_a
one
s file_a two
l
file_a
file_a
p file_a
two

d file_a
l
file_a
p file_a
one

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:

• System information (clock, sleep). How many operations per second? How to sleep or delay for a certain amount of time?
• A standard for BF interpreter performance (BMIPS) as employed in measuring the efficacy of BP interpreters, including JIT.
• External output channels other than the default stdin/stdout interface (storage, network, etc.).
• 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)

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:

• Simplifying zero operations and additive shifting operations.

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.

[aartaka]

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 (eeacb68) 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

[aartaka]

However, I've encountered an issue with the operating system where the file system functions more as a stack than a file directory.

To be precise, the data structure is Rotating Cached Relevance Stack ™️

Thanks,

Artyom Bologov
Lead Algorithmic Engineer
BF Enterprise Solutions