64-bit FORTH

Before I describe a 64-bit FORTH version, I need to explain something about the more-established, general 32-bit version of this low-level language. The 32-bit FORTH had an accepted method of storing 64-bit, so-called ‘double-width’ numbers, in two positions on the stack, with the most-significant word ‘on top’, and the less-significant word in second position from the ‘top’. Correspondingly, ‘normal’ 32-bit FORTH possesses special operators that can either perform full, double-width arithmetic, which treats two consecutive stack-positions as defining a single number, or mixed-width arithmetic, in which two single-width numbers can lead to a double-width product, or by which a double-width number can be divided by a single-width, to arrive at a single-width quotient, and optionally, also to arrive at a single-width modulus / remainder.

This is a fashion in which 32-bit CPUs have generally been able to perform 64-bit arithmetic, partially. And if the reader is not familiar with how this is accessible under FORTH, I can suggest This External Article as a source of reference.

But, if the reader has installed the 64-bit GNU FORTH, which is also just called ‘gforth’ under Linux, then I should call to his attention, that now, each stack-position is capable of holding a 64-bit number, and that all the operators on those numbers are possible, which would otherwise be available for 32-bit numbers, with no special naming.

The following is a small text-session-clip, that illustrates how this works:


dirk@Klystron:~$ gforth
Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
1 cells . 8  ok
hex  ok
$0123456789ABCDEF $100000000 /mod .s <2> 89ABCDEF 1234567  ok
$20 lshift + .s <1> 123456789ABCDEF  ok
dup  ok
m* .s <2> -235A1DF76F0D5ADF 14B66DC33F6AC  ok
d. 14B66DC33F6ACDCA5E20890F2A521  ok


So the ‘/mod’, the ‘lshift’ and the ‘+’ operators are spelled exactly as they would have been for 32-bit FORTH, but operate on potential 64-bit numbers. ‘gforth’ still preserves the double-width operators with the special naming, but in this case, double-width actually means 128-bit ! Its implementation of the standard Fetch operator, which is still named ‘@’, now fetches a 64-bit value from RAM. And I have already documented this slight incompatibility in This Earlier Posting.

If we can assume that our source-code is to be compiled on 64-bit FORTH, we can just perform 64-bit operations on single stack-positions, at will.

It should also be noted that in FORTH comments and stack-traces, the topmost stack-position is written on the right-hand side of the textual list. The apparent negative number above, in the second stack position from the logical top, after ‘ m* .s ‘ , is the result of the most-significant bit of that word being a (1) and not a (0). By convention, in signed integers, this will trigger that a negative number is meant, using two’s complement. And this is still the case, in hexadecimal. But, because this word is the less-significant of the two listed, its most-significant bit will no longer be the most-significant, after it has been combined with the other word, thereby again forming a positive number when printed out as a single 128-bit, signed, integer.

(Edit 07/31/2017 : )

One fact which I have blatantly ignored in my own coding, was that the way in which I chose to separate a single numeric value into two bit-fields – through a modulus-division – is not the most efficient in terms of how many CPU-clock-cycles it consumes. A preferable way to do the same thing, is by using ‘rshift’, and then masking.

The reason for this is the fact that when a CPU is instructed to left-shift or right-shift a binary register-content, doing so takes up about 1 clock-cycle per bit-position shifted. What people may not realize, is that although addition and subtraction can easily be performed in one step by logic-circuits, multiplication and division may not be, assuming a generic, general-purpose CPU. To multiply two 64-bit numbers, actually means to perform 64 additions optionally, each depending on the value of one bit. And to divide a 64-bit number by another, actually means to perform 64 subtractions optionally, each depending on the outcome of a comparison. Maybe for 32-bit or 16-bit registers, we don’t care. But by the time we’re using 64-bit numbers, it penalizes our CPU-load twice as much.

Continue reading 64-bit FORTH

I question the amount of VRAM on Phoenix.

I am still contemplating, why the server-box I name ‘‘ was crashing, and my attention keeps coming back to the graphics chip. Before this computer was resurrected, it was running in 32-bit mode, as ‘‘. At that time, it only had 2GB of RAM. But now it runs in 64-bit mode, with 4GB of RAM.

When I boot, the BIOS message still tells me that it has 128MB of shared memory, for the graphics chip. But strangely enough, the piece of text I pasted into this posting, reads that the graphics driver has set aside 256MB of VRAM, near the top of the 4GB of physical addresses. I did not know that the kernel can override a BIOS setting in this way, let us say just because processing has been switched to 64-bit mode.

One mishap which could naively go wrong, is that the legacy driver, unaware of the specifics of this motherboard, could be allocating 256MB of shared memory, but that physically, the hardware cannot share past the address ‘‘. That is, the address ‘‘ may have become forbidden territory for the graphics card. It is however uncommon, that the programmers of kernel-space modules, would make such a simple mistake.

This is a 64-bit system, which only accepts up to 4GB of RAM, thus only possessing 32-bit physical addresses, to go with its 64-bit virtual addresses.

According to this screen-shot:


I only have 3.74GB of RAM available to the system, instead of 4GB. The reason for this, is the fact that 256MB have in fact been reserved for the graphics chip. By itself this would seem to suggest, that the allocation has succeeded.

Also, the fact that 49.26MB of shared memory was momentarily being indicated, is not too telling, because several types of processes could be using shared memory for some purpose. This feature does not only exist, for user-space processes to make texture images available to the graphics card.

Continue reading I question the amount of VRAM on Phoenix.

Plausible does not mean Assumed

I could make hypothetical guesses, as to why crashes like this one happen, on the machine I name ‘Phoenix’, which was manufactured in 2008. This time I noticed, that the cursor on the screen stopped moving, then that mouse-input was not being interpreted, then that the screen just filled with an image, which was a diagonally-scrambled version of the normal screen content:

  • It could be that the old GPU is no longer reliable at the hardware level, and that it may now suffer from random crashes, which also crash the X-server. The “” (‘‘) feature I have seen the nVidia Driver execute properly in past situations, may just not kick in.
  • When I reinstalled, replacing the old 32-bit O/S with the current 64-bit O/S, I also replaced the 2GB of RAM with completely new, 4GB of RAM, and the “” (‘‘) of the new RAM has also become faster, that becoming 800MHz instead of the earlier 600MHz. Either set of DDR RAM modules was running with dual-channel capability. The motherboard may detect this capability of the new RAM modules and start using it, as the motherboard itself may have the stated capability of running at 800MHz. Yet, at 800MHz, the way this Motherboard works may not be stable.
  • There could be some sort of kernel issue…

What I do find a bit more specific, is the fact that there seem to be no log entries for the , suggesting that although an X-server crash eventually takes place, this may not be the root cause. Also, the fact that the mouse has become unresponsive for a few seconds, before screen-content collapses, seems to suggest the same thing…

But the most important fact for me to observe, is that simply being able to suggest plausible reasons for the crash, is not the same thing as having diagnosed the crashes. Honestly, I do not know at present, why this type of crash happens.

One of the observations about this machine which had impressed me in the past, was that I had pushed 3D rendering beyond the limits of the old GPU, thereby crashing this graphics chip, but that the desktop manager I had in place was able to restart the GPU, and to resume the session, without requiring any action from me, but displaying a well-behaved message to the effect that the GPU needed to be rebooted. This is called “” (‘‘), and does the same thing under Linux, that it does under Windows, and depends on stable graphics drivers.

The fact that I do possess ‘‘ on this machine suggests, that a simple failure of the graphics chip, should not take out my session.


According to my latest inquiry, this Motherboard is ‘only’ running at 66MHz. Therefore, the maximum speed of the newer RAM Module should not be an issue after all.



Continue reading Plausible does not mean Assumed

Chrome For Linux Upgrade Glitch Fixed By Google

One of the facts which I had observed about the Google Chrome browser version, which is meant for Linux, was that Google no longer provides a 32-bit version of its binaries. In keeping with this, Google has also removed the section in its code repository, which would make a 32-bit version available. Hence, I can only be subscribing to the 64-bit upgrades. Yet, my Linux computer ‘Phoenix’ has its package manager set up, to query a repository for both the 64-bit and the 32-bit versions of any package by default, and then to download and install the packages which are relevant.

In this earlier posting, I observed how this can lead to an error message when running ‘apt-get update‘. What I had done, was to make minor configuration changes like so, which I had needed to re-apply, after every upgrade to Chrome.

Well Google has caught up with the scenario which I was describing. As of their latest upgrade, their own ‘cron.daily‘ symlink will properly put the following source into ‘/etc/apt/sources.list.d/google-chrome.list‘ :

deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

You may note, that the script from Google now includes the ‘[arch=amd64]‘ parameter, which means that I won’t have to make any manual adjustments to this configuration detail of my machine, every time the Chrome browser receives an upgrade.

Thank you, Google!