Re: BASIC OS for the PC

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Wed, 21 Dec 2016 10:49:56 +0100
Message-ID: <20161221094956.GA6104@hermes.local.trikaliotis.net>
Hello Ruud,

* On Wed, Dec 21, 2016 at 06:58:50AM +0000 Baltissen, GJPAA (Ruud) wrote:
 
> > as always, I will not ask for the "why" and just go directly into
> > the details. ;)
> 
> In fact it was triggered by a Linux guru here at work who said that
> creating an OS was doable for one person. And I must say it is best a
> bit of fun. I certainly learned a lot about The BIOS, FAT and other
> disk related material.

It depends upon what you mean by an OS. It is perfectly doable,
especially if it is somehow special purpose and you do not need to make
it to do everything.
 
> > Is the source available somewhere? ;)
> 
> Not on Internet, yet. But you are free to send an email to get the
> stuff. I must warn you: although it is well documented (IMHO), it is
> still quite a lot of rough material with lots of try (and error) code.

You will get an e-mail. ;)

 
> > Is there a garbage collection in the variable area?
> 
> Very good question. So far none. But there is a simple reason for
> that: I still don't understand what garbage collection exactly does.
> In my understanding, if I understood Wikipedia correctly, the most
> less used variables are disposed. But in my opinion that is crazy. And
> AFAIK Pascal and C don't have garbage collection either. Why not if it
> is such a "good" tool?  If someone is willing to explain in other
> words what garbage collection exactly does, what its benefits plus the
> assurance that it won't jeopardize any program, I might install it in
> time (in 10 years or so :)

Well, the C64 BASIC has a garbage collection (GC), too.

Think about the string variables: As soon as these are not only
assignments of the form A$="ABC" from the program text, in which case
the pointer points into the program area, the strings are generated on
the string area (the end of the basic memory, that is, from $A000 going
downwards). Thus, the string variable pointer points to the string
there.

Now, you do string manipulations (for example, something like A$ =
B$+B$, or then B$=something else). After these transformatios, the old
values of A$ (first assignment) or B$ (second assignment) or not needed
anymore. In CBM BASIC, these "old" strings remain as garbase in the
string area.

If you do many of these manipulations, then the end of the string area
(which grows down, remember) will eventually hit the end of the variable
(array) area. When this happens, the BASIC could output "?OUT OF MEMORY
ERROR"

But wait: There are possibly many strings in the string area that are
only garbage. Thus, the BASIC starts a GC and tries to stuff all the
strings together so that the garbage does not occupy any memory anymore.
For this, it looks which strings are still used (by checking which
pointers to the string area still exist), and removing everything in
between.

Unfortunately, the implementation in the CBM BASIC (MS BASIC) has a
complexity of O(n^2), that's the reason why this can take much time (I
have had cases in which it needed half an hour! In this time, you
believe that the computer has crashed, as there is no progress at all).

Only if after the GC, there is still not enough room, you get the "?OUT
OF MEMORY ERROR", and the program stops.

The GC in the C64 BASIC starts at $B526, btw.

Starting with the 264 series, CBM used a better approach for GC. In
order to allow for this, every string in the string area contained a
"back link" to the string descriptor, if it was still used, or a special
sign (0 byte, IIRC) and the length of the garbage area, so the algorithm
could run in O(n) instead.


Note that the GC in BASIC does NOT try to remove the 7 byte variable
memory that is generated for every variable after the BASIC area (or the
x byte for any array). The benefit is not much, and you could only
remove variables that are already "restored" to the base value (0 for
numeric ones, empty string for strings). One could do this, but I am not
sure if the benefit is high enough to justify this.
 
> Marko:> guess on this group we would want to concentrate on the
> simpler CPUs with no MMU or virtual memory, that is, at most 8086 or
> 80286. :)
> 
> That's exactly what I had in mind. For 386+ you have Linux, Minix and
> other OSes.

My first attempt on an OS was exactly the opposite, I wanted to create a
386 based OS. I did not go very far, though, because of lack of time. :(

> FYI: tomorrow we will go to Poland to spend Christmas there. And my
> parents-in-law don't have internet. So don't expect any replies from
> me for the time being. Which leaves me one thing to say:

No internet? How that? ;)

>          Merry Christmas and Happy New Year !!!

Enjoy your free time!

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list
Received on 2016-12-21 10:00:22

Archive generated by hypermail 2.2.0.