You can see it here: https://www.youtube.com/watch?v=1a2rvx0x7k8
This time we test a quote from Michael Dell. Was he right - or not?
Hans Bezemer
On 30/07/2022 03:39, Hans Bezemer wrote:[..]
You can see it here: https://www.youtube.com/watch?v=1a2rvx0x7k8
This time we test a quote from Michael Dell. Was he right - or not?
How to recognize a 'smart person'? By their success. Which is too
late. All the rabbits have been pulled from that particular hat.
How to recognize a 'smart person'? By their success. Which is too
late. All the rabbits have been pulled from that particular hat.
The world is full of smart people that don't have success,
and certainly not with everything that they do.
[..]The world is full of smart people that don't have success,Hi Marcel, nice to see you.
and certainly not with everything that they do.
Your statement looks like you are talking about yourself.
Don't make a bitter victim of yourself. Nobody needs it.
Hi Marcel, nice to see you.
Your statement looks like you are talking about yourself.
Don't make a bitter victim of yourself. Nobody needs it.
You better get a grip and start competing with Stephen, who of you will write the best 64-bit Forth.
His 64-bit VFX Forth is still going through a transition. Quite a few things don't work in it yet. For example (tested under Linux) when you SET-SIZE the dictionary to 3GB and SAVE and reload VFX Forth and you ALLOT 2GB of data, then newly written words are compiled wrong, becuase VFX Forth always CALLs them using relative 32-bit signed displacement. Even his disassembler then disassembly wrong that situation. But of course this is why we dream about 64-bit Forths, to have multi-gigabyte dictionaries at our disposal.
In response to:
How to recognize a 'smart person'? By their success. Which is too
late. All the rabbits have been pulled from that particular hat.
Marcel Hendrix wrote:
The world is full of smart people that don't have success,
and certainly not with everything that they do.
Hi Marcel, nice to see you.
Your statement looks like you are talking about yourself.
Don't make a bitter victim of yourself. Nobody needs it.
You better get a grip and start competing with Stephen, who of you will write the best 64-bit Forth.
iForth was the first big 64-bit Forth on the market, but you made iForth too weird to be successful.
And too expansive.
You wrote on your weird web page: "It is not my intention to take away business from regular Forth vendors."It is a misconception that a GPL-ed Forth takes away business, there Marcel
And you didn't.
But you can still succeed. You have the knowledge, don't waste it.
It's not like this, than Stephen has already taken all the rabbits out of that particular hat.
His 64-bit VFX Forth is still going through a transition. Quite a few things don't work in it yet. For example (tested under Linux) when you SET-SIZE the
dictionary to 3GB and SAVE and reload VFX Forth and you ALLOT 2GB of data, then newly written words are compiled wrong, becuase VFX Forth always CALLs them
using relative 32-bit signed displacement. Even his disassembler then disassembly wrong that situation. But of course this is why we dream about 64-bit
Forths, to have multi-gigabyte dictionaries at our disposal.
Well, Marcel, you have something to do. Be the first and waste no more time.
On 31 Jul 2022 at 09:34:31 CEST, "Michał Kasprzak" <siarczek83@gmail.com>
For example (tested under Linux) when you SET-SIZE the
dictionary to 3GB and SAVE and reload VFX Forth and you ALLOT 2GB of data, >> then newly written words are compiled wrong, becuase VFX Forth always CALLs >> them using relative 32-bit signed displacement. Even his disassembler then >> disassembly wrong that situation. But of course this is why we dream about >> 64-bit Forths, to have multi-gigabyte dictionaries at our disposal.
Well the, write a multi-gigabyte app. The largest Forth app I know of compiles >1.4 million lines of code to 33 Mb in 29 seconds with 32 bit VFX Forth.
bar^
: foo ." foo" ; ok
2 1024 * 1024 * 1024 * allot ok
: bar foo ; ok
bar
... register dump elided ...
--- RS top ---
$0000:0000:804E:3EB5 BAR
$0000:0000:0042:7312 (INTERPRET)
$0000:0000:0042:7893 DEFER
$0000:0000:0042:7D71 CATCH
...
Signal number SIGSEGV
at address 0000:0001:004E:3E60, probably in * outside dictionary *
In response to:words are compiled wrong, becuase VFX Forth always CALLs them using relative 32-bit signed displacement. Even his disassembler then disassembly wrong that situation. But of course this is why we dream about 64-bit Forths, to have multi-gigabyte
How to recognize a 'smart person'? By their success. Which is too
late. All the rabbits have been pulled from that particular hat.
Marcel Hendrix wrote:
The world is full of smart people that don't have success,
and certainly not with everything that they do.
Hi Marcel, nice to see you.
Your statement looks like you are talking about yourself.
Don't make a bitter victim of yourself. Nobody needs it.
You better get a grip and start competing with Stephen, who of you will write the best 64-bit Forth.
iForth was the first big 64-bit Forth on the market, but you made iForth too weird to be successful.
And too expansive.
You wrote on your weird web page: "It is not my intention to take away business from regular Forth vendors."
And you didn't.
But you can still succeed. You have the knowledge, don't waste it.
It's not like this, than Stephen has already taken all the rabbits out of that particular hat.
His 64-bit VFX Forth is still going through a transition. Quite a few things don't work in it yet. For example (tested under Linux) when you SET-SIZE the dictionary to 3GB and SAVE and reload VFX Forth and you ALLOT 2GB of data, then newly written
Well, Marcel, you have something to do. Be the first and waste no more time.
On 31/07/2022 17:34, Michał Kasprzak wrote:words are compiled wrong, becuase VFX Forth always CALLs them using relative 32-bit signed displacement. Even his disassembler then disassembly wrong that situation. But of course this is why we dream about 64-bit Forths, to have multi-gigabyte
In response to:
How to recognize a 'smart person'? By their success. Which is too
late. All the rabbits have been pulled from that particular hat.
Marcel Hendrix wrote:
The world is full of smart people that don't have success,
and certainly not with everything that they do.
Hi Marcel, nice to see you.
Your statement looks like you are talking about yourself.
Don't make a bitter victim of yourself. Nobody needs it.
You better get a grip and start competing with Stephen, who of you will write the best 64-bit Forth.
iForth was the first big 64-bit Forth on the market, but you made iForth too weird to be successful.
And too expansive.
You wrote on your weird web page: "It is not my intention to take away business from regular Forth vendors."
And you didn't.
But you can still succeed. You have the knowledge, don't waste it.
It's not like this, than Stephen has already taken all the rabbits out of that particular hat.
His 64-bit VFX Forth is still going through a transition. Quite a few things don't work in it yet. For example (tested under Linux) when you SET-SIZE the dictionary to 3GB and SAVE and reload VFX Forth and you ALLOT 2GB of data, then newly written
Well, Marcel, you have something to do. Be the first and waste no more time.Oh dear. What will become of the world when the consumer starts asking for more?
https://youtu.be/upD6cB9Rzvk
It's not necessary to have many source lines to replicate his findings
and experience this limitation of VFX:
On 31 Jul 2022 at 18:13:19 CEST, "Anton Ertl" <Anton Ertl> wrote:
It's not necessary to have many source lines to replicate his findings
and experience this limitation of VFX:
Blah, blah, blah ...
I have never doubted that the failure exists. What is the use case of 2 GB ALLOT and not using the space? We/I/MPE have made the assumption that all code
is in one contiguous section. Show me a use case that breaks this. The only cases that make sense are transient code in ALLOCATEd memory and code in binary overlays. Only the first has been asked for by an MPE client - see Examples/transients.fth.
Stephen
P.S. Chuck has repeatedly warned us against coding for problem that don't exist until they may exist.
I would also posit that a 2GB chunk of code is either something created dynamically for a special use (e.g. rainbow trees or the like), or (more likely) a poor implementation of something.
In almost 40 years of coding, I've never written a program that needed
2G of code space (or, for that matter, 100M). Data space on the other
hand, well, that's another story.
I would also be very skeptical that a program requiring 2G of code space
was tested and stable.
Blah, blah, blah ...
What is the use case of 2 GB
ALLOT and not using the space?
We/I/MPE have made the assumption that all code
is in one contiguous section.
bar^
Show me a use case that breaks this.
The only
cases that make sense are transient code in ALLOCATEd memory and code in >binary overlays.
P.S. Chuck has repeatedly warned us against coding for problem that don't >exist until they may exist.
Inside Gorth you can display the sections as follows:
Stephen Pelc <stephen@vfxforth.com> writes:
Blah, blah, blah ...
Very mature.
What is the use case of 2 GB
ALLOT and not using the space?
That's a minimal example, not a use case.
We/I/MPE have made the assumption that all code
is in one contiguous section.
If your assumption is that there are no sequences like:
: ... ;
... allot
\ or
... , ... ,
: ... ;
in Forth code, that assumption is wrong for many Forth programs. I
certainly don't write Forth code satisfying your constraint.
Mixing code and data has resulted in slowdowns in VFX already many
years ago, and instead of eliminating it, you tried workarounds for
that with mixed success (but you are not alone in that). Now you are
pointed to another problem resulting from this mixing, but you claim
it does not exist.
- anton
In article <2022Aug1.093350@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
...
in Forth code, that assumption is wrong for many Forth programs. I >>certainly don't write Forth code satisfying your constraint.
I have a lot of project euler examples, and it is just not practical
to have enormous space allotted, and then go on compiling.
So I adopt a strategy
- in experimental stage / test stage : small buffer
- in production I re-allot buffers in run time mostly running a
compiled program typically using (if must be) a 8 Gbyte space.
You must understand that MPE make her customisers happy, not
cater for academic objections.
On 1/08/2022 17:45, Ron AARON wrote:
I would also posit that a 2GB chunk of code is either something created
dynamically for a special use (e.g. rainbow trees or the like), or (more
likely) a poor implementation of something.
In almost 40 years of coding, I've never written a program that needed
2G of code space (or, for that matter, 100M). Data space on the other
hand, well, that's another story.
I would also be very skeptical that a program requiring 2G of code space
was tested and stable.
Do we know what 64-bit compilers in other domains are providing? When competing for users, personal experience and needs isn't necessarily the deciding factor. E.g. when Forth Inc implemented 200x character literals they said they didn't agree with it. Satisfying customer expectations is what clinched it - as misguided as those expectations may have been.
I have a lot of project euler examples, and it is just not practical
to have enormous space allotted, and then go on compiling.
So I adopt a strategy
- in experimental stage / test stage : small buffer
- in production I re-allot buffers in run time mostly running a
compiled program typically using (if must be) a 8 Gbyte space.
You must understand that MPE make her customisers happy, not
cater for academic objections.
Mixing code and data has resulted in slowdowns in VFX already many
years ago, and instead of eliminating it, you tried workarounds for
that with mixed success (but you are not alone in that). Now you are >>pointed to another problem resulting from this mixing, but you claim
it does not exist.
Which other systems do work arounds?
The only systems that comes to mind
are kforth and iforth. Others seem to be not involved in humongous
system.
On 01/08/2022 11:40, dxforth wrote:
Do we know what 64-bit compilers in other domains are providing? When
competing for users, personal experience and needs isn't necessarily the
deciding factor. E.g. when Forth Inc implemented 200x character literals
they said they didn't agree with it. Satisfying customer expectations is
what clinched it - as misguided as those expectations may have been.
I guess a good question would be what are the limits of gcc 64-bit (say, >Intel) versions? I never tried to compile such an enormous program, and
from my experience I think it would probably take a very long time, and
then give up.
But that's just talk; I never tried it.
albert@cherry.(none) (albert) writes:
I have a lot of project euler examples, and it is just not practical
to have enormous space allotted, and then go on compiling.
Why not? Works just fine in Gforth, you just need to tell it what
dictionary size you want.
Small systems are affected by slowdowns from code/data mixing as much
as large or homungous systems are. Let's see how things turn out in
various systems:
Results (on a Ryzen 5800X)
cycles
932_020_442 gforth-fast development
13_886_103_537 iforth
622_600_649 lxf
8_809_460_083 VFX64
The penalty used to be higher on earlier CPUs, but it's still
significant.
- anton--
Ron AARON <clf@8th-dev.com> writes:
On 01/08/2022 11:40, dxforth wrote:
Do we know what 64-bit compilers in other domains are providing? When
competing for users, personal experience and needs isn't necessarily the >>> deciding factor. E.g. when Forth Inc implemented 200x character literals >>> they said they didn't agree with it. Satisfying customer expectations is >>> what clinched it - as misguided as those expectations may have been.
I guess a good question would be what are the limits of gcc 64-bit (say,
Intel) versions? I never tried to compile such an enormous program, and >>from my experience I think it would probably take a very long time, and
then give up.
But that's just talk; I never tried it.
Ok, I tried a C version of the Forth program that VFX5.11 crashed on:
The Forth program:
: foo ." foo" ;
2 1024 * 1024 * 1024 * allot
: bar foo ;
bar
[c8b:/tmp:83565] cat xxx.c
#include <stdio.h>
void foo() {
printf("foo");
}
char x[2L*1024*1024*1024];
int main() {
foo();
return 0;
}
[c8b:/tmp:83566] time gcc -O xxx.c
real 0m0.032s
user 0m0.019s
sys 0m0.013s
[c8b:/tmp:83567] ls -l a.out
-rwxr-xr-x 1 anton 29015 16656 Aug 1 15:04 a.out*
[c8b:/tmp:83568] size a.out
text data bss dec hex filename
1507 584 2147483680 2147485771 8000084b a.out [c8b:/tmp:83569] ./a.out
foo[c8b:/tmp:83570]
[c8b:/tmp:83570] objdump -d a.out
...
0000000000001135 <foo>:
1135: 48 83 ec 08 sub $0x8,%rsp
1139: 48 8d 3d c4 0e 00 00 lea 0xec4(%rip),%rdi # 2004 <_IO_stdin_used+0x4>
1140: b8 00 00 00 00 mov $0x0,%eax
1145: e8 e6 fe ff ff callq 1030 <printf@plt>
114a: 48 83 c4 08 add $0x8,%rsp
114e: c3 retq
000000000000114f <main>:
114f: 48 83 ec 08 sub $0x8,%rsp
1153: b8 00 00 00 00 mov $0x0,%eax
1158: e8 d8 ff ff ff callq 1135 <foo>
115d: b8 00 00 00 00 mov $0x0,%eax
1162: 48 83 c4 08 add $0x8,%rsp
1166: c3 retq
1167: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
116e: 00 00
Somehow gcc has no problem with source code that interleaves code and
big data. It does not even take long in this case.
- anton
In article <2022Aug1.122649@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Small systems are affected by slowdowns from code/data mixing as much
as large or homungous systems are. Let's see how things turn out in >>various systems:
I can assemble a version of ciforth where all code is collated in a
small space. With a indirect threading Forth the rest is data.
Would that worth while to try, even only as an experiment?
<SNIP>1_010_111_863 gforth-itc development
Results (on a Ryzen 5800X)
cycles
932_020_442 gforth-fast development
13_886_103_537 iforth
622_600_649 lxf
8_809_460_083 VFX64
The penalty used to be higher on earlier CPUs, but it's still
significant.
I understand lower is better. Does that mean in this benchmark
iforth is an order of magnitude slower that gforth-fast?
Unbelievable!
[..]Which other systems do work arounds?The typical workaround is to use padding between code and data so they
are not in the same cache line. This seems to be pretty common. Let's see how >The only systems that comes to mind
are kforth and iforth. Others seem to be not involved in humongousSmall systems are affected by slowdowns from code/data mixing as much
system.
as large or homungous systems are. Let's see how things turn out in
various systems:
I notice that even systems that mix data and native code (iForth,[..]
SwiftForth, VFX) don't pad between the end of a colon definition and
the invocation of HERE. This means that we may see performance
problems for code patterns like:
I had to make sure that the alignment of iForth does not interfere, so
I inserted some gratuitious code before the loop; for VFX64 5.11 RC2
[build 0112] I had to then insert a 48 allot before loading the code
above.
Results (on a Ryzen 5800X)
cycles
932_020_442 gforth-fast development
13_886_103_537 iforth
622_600_649 lxf
8_809_460_083 VFX64
The penalty used to be higher on earlier CPUs, but it's still
significant.
13_886_103_537 ????
there are only 9000*9000/2 numbers to consider, which is about 4e7...
So you would need a bit vector of about 5MB, not anything like 2.7GB.
Ramanujan's taxi
<http://www.complang.tuwien.ac.at/forth/programs/taxi.fs> will take a
lot of dictionary memory, depending on the parameters; e.g., for the
taxi numbers up to 9000 development Gforth takes 2.7GB....
Paul Rubin <no.e...@nospam.invalid> writes:
there are only 9000*9000/2 numbers to consider, which is about 4e7...No wait, that won't work. Need more coffee. Sorry. It still seems
So you would need a bit vector of about 5MB, not anything like 2.7GB.
like enough to make a list of the 4e7 sums, sort it, and check for duplicates. So you need 64 bits per sum instead of 1 bit, i.e. around
300MB. I hope I have it right this time. Maybe I will code it and see.
Be aware that taxi.fs is mainly for testing execute-parsing that sets
up its own temporary wordlists internally. It seems rather inefficient
to me.
Be aware that taxi.fs is mainly for testing execute-parsing that
sets up its own temporary wordlists internally. It seems rather inefficient >to me.
On Monday, August 1, 2022 at 2:45:23 PM UTC+2, Anton Ertl wrote:
I notice that even systems that mix data and native code (iForth,[..]
SwiftForth, VFX) don't pad between the end of a colon definition and
the invocation of HERE. This means that we may see performance
problems for code patterns like:
I had to make sure that the alignment of iForth does not interfere, so
I inserted some gratuitious code before the loop; for VFX64 5.11 RC2
[build 0112] I had to then insert a 48 allot before loading the code
above.
Results (on a Ryzen 5800X)
Same here.
cycles
932_020_442 gforth-fast development
13_886_103_537 iforth
622_600_649 lxf
8_809_460_083 VFX64
The penalty used to be higher on earlier CPUs, but it's still
significant.
Slightly modified (I wanted ticks, and check F! vs DF!), maybe that is significant?
hex
: foo1
ticks-reset cr ." foo1 takes " [ticks
#100000000 2dup swap ! 2dup swap cell+ ! 0 do fdup dup f! loop [ here cr . ] ticks]
ticks? (n,3) ." ticks" ;
: foo2
ticks-reset cr ." foo2 takes " [ticks
#100000000 2dup swap ! 2dup swap cell+ ! 0 do fdup dup f! loop [ here cr . ] ticks]
ticks? (n,3) ." ticks" ;
FORTH> in
13407D1
1340941
13409E0
13409E0
foo1 takes 485,739,712 ticks
foo2 takes 485,579,048 ticks ok
13_886_103_537 ????
On 01/08/2022 11:40, dxforth wrote:
On 1/08/2022 17:45, Ron AARON wrote:
I would also posit that a 2GB chunk of code is either something created
dynamically for a special use (e.g. rainbow trees or the like), or (more >> likely) a poor implementation of something.
In almost 40 years of coding, I've never written a program that needed
2G of code space (or, for that matter, 100M). Data space on the other
hand, well, that's another story.
I would also be very skeptical that a program requiring 2G of code space >> was tested and stable.
Do we know what 64-bit compilers in other domains are providing? When competing for users, personal experience and needs isn't necessarily the deciding factor. E.g. when Forth Inc implemented 200x character literals they said they didn't agree with it. Satisfying customer expectations is what clinched it - as misguided as those expectations may have been.
I guess a good question would be what are the limits of gcc 64-bit (say, Intel) versions? I never tried to compile such an enormous program, and
from my experience I think it would probably take a very long time, and
then give up.
Ron AARON <clf@8th-dev.com> wrote:
On 01/08/2022 11:40, dxforth wrote:
On 1/08/2022 17:45, Ron AARON wrote:
I would also posit that a 2GB chunk of code is either something created >>>> dynamically for a special use (e.g. rainbow trees or the like), or (more >>>> likely) a poor implementation of something.
In almost 40 years of coding, I've never written a program that needed >>>> 2G of code space (or, for that matter, 100M). Data space on the other
hand, well, that's another story.
I would also be very skeptical that a program requiring 2G of code space >>>> was tested and stable.
Do we know what 64-bit compilers in other domains are providing? When
competing for users, personal experience and needs isn't necessarily the >>> deciding factor. E.g. when Forth Inc implemented 200x character literals >>> they said they didn't agree with it. Satisfying customer expectations is >>> what clinched it - as misguided as those expectations may have been.
I guess a good question would be what are the limits of gcc 64-bit (say,
Intel) versions? I never tried to compile such an enormous program, and
from my experience I think it would probably take a very long time, and
then give up.
AFAIK single part of program is limited to 2G. If you are lucky
(like in Anton example) up to 4G may work. This is due to signed
32-bit offsets. IIUC gcc itself does not do anything very smart,
simply marks sections as code, initialized data (writeable),
read-only data and zero initalized data. On Linux assemble+linker
puts data after code.
If you need bigger program you are supposed to split it into
parts: main program is a part but every shared library counts
as separate part. So you may have 1000 shared libraries each
say 1G of code for total 1000G. If you need single piece of
data that is bigger than 2G you are supposed to dynamically
allocate it, say using malloc. To initalize such data you
need extra code (which in same languages may be generated
by compiler).
More generally, as long as single function stays below 2G
(with resonable margin) linker could insert intermedate
jumps (similar to what is used to implement shared libraries)
to allow calls to arbitrary locations. To allow big static
data is more tricky: such data must be addressed by pointers.
gcc folks wrote that uniformly accessing all data via
pointers causes about 7% slowdown, which was deemed to
high cost compared to benefits.
OTOH most dynamic languages that generate native code
seem to use general model: main cost is due to data
and it is hard to avoid. And some costs are due
to language features and would appear anyway.
Marcel Hendrix <m...@iae.nl> writes:[..]
On Monday, August 1, 2022 at 2:45:23 PM UTC+2, Anton Ertl wrote:
The end of the loop and the data have to be in the same cache line to demonstrate the problem.[..]
Of course, the good thing is that the problem will rarely occur in the[..]
wild; but OTOH, you might do some seemingly innocuous change, and see a significant slowdown, if you are unlucky.
I assume the possibility to comma data straight after code is deliberate, >given the conventional use of DOES> .
There is not much I can do for now,
apart from an extra ";" action.
On 02/08/2022 2:35, antispam@math.uni.wroc.pl wrote:
AFAIK single part of program is limited to 2G. If you are lucky
(like in Anton example) up to 4G may work. This is due to signed
32-bit offsets. IIUC gcc itself does not do anything very smart,
simply marks sections as code, initialized data (writeable),
read-only data and zero initalized data. On Linux assemble+linker
puts data after code.
Yes, exactly. In particular, in the example Anton posted directly after
my posting this question, the "huge" array was simply a pointer to BSS,
which is just allocated by the OS upon loading the executable (subject
to system memory constraints, of course).
My question was directed at the TEXT segment size, e.g. how much
functional code can be stuffed into an executable. I think the answer
is: "that depends".
At run-time, only the "live" parts of the code will be mmap-ed
More generally, as long as single function stays below 2G
(with resonable margin) linker could insert intermedate
jumps (similar to what is used to implement shared libraries)
to allow calls to arbitrary locations. To allow big static
data is more tricky: such data must be addressed by pointers.
gcc folks wrote that uniformly accessing all data via
pointers causes about 7% slowdown, which was deemed to
high cost compared to benefits.
Right, which is why loading huge data externally, via mmap or the
equivalent is what makes sense. Let the OS do the heavy lifting and
access the huge data like a big array of bytes (etc).
Ron AARON <clf@8th-dev.com> writes:
On 02/08/2022 2:35, antispam@math.uni.wroc.pl wrote:
AFAIK single part of program is limited to 2G. If you are lucky
(like in Anton example) up to 4G may work. This is due to signed
32-bit offsets. IIUC gcc itself does not do anything very smart,
simply marks sections as code, initialized data (writeable),
read-only data and zero initalized data. On Linux assemble+linker
puts data after code.
Yes, exactly. In particular, in the example Anton posted directly after
my posting this question, the "huge" array was simply a pointer to BSS,
which is just allocated by the OS upon loading the executable (subject
to system memory constraints, of course).
That's the point. In the source code there is a C function, an array,
and another C function, and gcc handles this just fine by putting the functions into the text segment, and the array in the bss segment. By contrast, VFX does not do this separation, and fails.
If I increase the array to 5GB, gcc still compiles it just fine.
However, if I initialize the array (so it goes into the data rather
than the bss segment), I get a linker error:
Maybe one can get the linker to behave with linker flags, but one can
say that with initialized data, the C ecosystem does not do better
than VFX (and worse than Gforth).
My question was directed at the TEXT segment size, e.g. how much
functional code can be stuffed into an executable. I think the answer
is: "that depends".
Given that they don't manage data segments beyond 2GB (at least by
default), they probably don't manage text segments beyond 2GB,
either. I doubt there is user demand for that; despite C++, code
segments, and also the sum of r-x mappings (i.e., code summed across
all shared objects) in single processes tends to be much smaller than
2GB. I dimly remember summing up the sizes of all text segments in
binaries and libraries in my Linux system, and getting less than 2GB.
At run-time, only the "live" parts of the code will be mmap-ed
What makes you think so? Why should anyone track liveness of code
(whatever that is), and unmap regions that are dead?
If there is a
memory crunch, code that has been demand-paged in and has not been
used in a while will be droped from main memory, to be demand-paged
back in when it is needed; but it's mapped all the time.
More generally, as long as single function stays below 2G
(with resonable margin) linker could insert intermedate
jumps (similar to what is used to implement shared libraries)
to allow calls to arbitrary locations. To allow big static
data is more tricky: such data must be addressed by pointers.
gcc folks wrote that uniformly accessing all data via
pointers causes about 7% slowdown, which was deemed to
high cost compared to benefits.
The alternative is what? Do you have a reference to this claim?
Right, which is why loading huge data externally, via mmap or the
equivalent is what makes sense. Let the OS do the heavy lifting and
access the huge data like a big array of bytes (etc).
If it's in a binary, it's also loaded by the loader with mmap(). The advantage is that you as programmer do not need to write the mmap()
call. OTOH, you typically have such huge amounts of data as files and
not as source code, so using mmap() may be less work.
- anton
In article <tca7gk$18tnv$1@dont-email.me>, Ron AARON <clf@8th-dev.com> wrote:
Yes, exactly. In particular, in the example Anton posted directly after
my posting this question, the "huge" array was simply a pointer to BSS,
which is just allocated by the OS upon loading the executable (subject
to system memory constraints, of course).
My question was directed at the TEXT segment size, e.g. how much
functional code can be stuffed into an executable. I think the answer
is: "that depends".
I think you're correct that a 2G limitation on individual code segments
is in place, though the linker can stitch together any number of such
segments. At run-time, only the "live" parts of the code will be mmap-ed
so unless the programmer created a function 2G in size (!) that probably
wouldn't be itself an issue on most modern systems.
ciforth has a classic uniform memory space. Linux put no constraint
to this.
S[ 3 ] OK ~/euler$ lina8G -a
5,000,000,000 ALLOT
OK
'+ >CFA CONSTANT +code
OK
WANT ASSEMBLER
OK
CODE +' +code HERE 100 MOVE 110 ALLOT
OK
OK
1 2 +'
OK
.S
S[ 3 ] OK
OK
BYE
What I've done here is copy the relocatable code to HERE.
So there you have it, machine code 5 gbyte up in the air.
[SAVE-SYSTEM is not working but that is my fault.
I guessed nobody would SAVE-SYSTEm beyond 2 gbyte.]
If you need bigger program you are supposed to split it into
parts: main program is a part but every shared library counts
as separate part. So you may have 1000 shared libraries each
say 1G of code for total 1000G. If you need single piece of
data that is bigger than 2G you are supposed to dynamically
allocate it, say using malloc. To initalize such data you
need extra code (which in same languages may be generated
by compiler).
You could probably have multiple 2G chunks of code linked together
statically, though you would also probably be waiting a while for the
link to complete.
If you have 1000 shared libraries, you have to think about static
linking. In the old days, you linked in exactly the code that you
needed. Nowadays you link if there is no tomorrow.
For data, it's less interesting. The most reasonable thing is, of
course, to put huge data chunks external to the program and load them at
need; but if you had to, you could probably include massive data chunks
(each less than 2G) and "manually" stitch them together (e.g. an array
of pointers to each chunk, or similar).
I prefer a huge swap space over mmap.
Right, which is why loading huge data externally, via mmap or the
equivalent is what makes sense. Let the OS do the heavy lifting and
access the huge data like a big array of bytes (etc).
<SNIP>
Groetjes Albert
my posting this question, the "huge" array was simply a pointer to BSS,
which is just allocated by the OS upon loading the executable (subject
to system memory constraints, of course).
My question was directed at the TEXT segment size, e.g. how much
functional code can be stuffed into an executable. I think the answer
is: "that depends".
I think you're correct that a 2G limitation on individual code segments
is in place, though the linker can stitch together any number of such >segments. At run-time, only the "live" parts of the code will be mmap-ed
so unless the programmer created a function 2G in size (!) that probably >wouldn't be itself an issue on most modern systems.
If you need bigger program you are supposed to split it into
parts: main program is a part but every shared library counts
as separate part. So you may have 1000 shared libraries each
say 1G of code for total 1000G. If you need single piece of
data that is bigger than 2G you are supposed to dynamically
allocate it, say using malloc. To initalize such data you
need extra code (which in same languages may be generated
by compiler).
You could probably have multiple 2G chunks of code linked together >statically, though you would also probably be waiting a while for the
link to complete.
For data, it's less interesting. The most reasonable thing is, of
course, to put huge data chunks external to the program and load them at >need; but if you had to, you could probably include massive data chunks
(each less than 2G) and "manually" stitch them together (e.g. an array
of pointers to each chunk, or similar).
Right, which is why loading huge data externally, via mmap or the
equivalent is what makes sense. Let the OS do the heavy lifting and
access the huge data like a big array of bytes (etc).
Ron AARON <clf@8th-dev.com> writes:
On 02/08/2022 2:35, antispam@math.uni.wroc.pl wrote:
AFAIK single part of program is limited to 2G. If you are lucky
(like in Anton example) up to 4G may work. This is due to signed
32-bit offsets. IIUC gcc itself does not do anything very smart,
simply marks sections as code, initialized data (writeable),
read-only data and zero initalized data. On Linux assemble+linker
puts data after code.
Yes, exactly. In particular, in the example Anton posted directly after
my posting this question, the "huge" array was simply a pointer to BSS, >which is just allocated by the OS upon loading the executable (subject
to system memory constraints, of course).
That's the point. In the source code there is a C function, an array,
and another C function, and gcc handles this just fine by putting the functions into the text segment, and the array in the bss segment. By contrast, VFX does not do this separation, and fails.
If I increase the array to 5GB, gcc still compiles it just fine.
However, if I initialize the array (so it goes into the data rather
than the bss segment), I get a linker error:
Maybe one can get the linker to behave with linker flags, but one can
say that with initialized data, the C ecosystem does not do better
than VFX (and worse than Gforth).
At run-time, only the "live" parts of the code will be mmap-ed
What makes you think so? Why should anyone track liveness of code
(whatever that is), and unmap regions that are dead? If there is a
memory crunch, code that has been demand-paged in and has not been
used in a while will be droped from main memory, to be demand-paged
back in when it is needed; but it's mapped all the time.
More generally, as long as single function stays below 2G
(with resonable margin) linker could insert intermedate
jumps (similar to what is used to implement shared libraries)
to allow calls to arbitrary locations. To allow big static
data is more tricky: such data must be addressed by pointers.
gcc folks wrote that uniformly accessing all data via
pointers causes about 7% slowdown, which was deemed to
high cost compared to benefits.
The alternative is what? Do you have a reference to this claim?
I prefer a huge swap space over mmap.
I prefer a huge swap space over mmap.
That's not an alternative.
Apart from that, have you tried a huge swap space?
My experience is that swap space on HDDs has become impractical a
while ago, because RAM has become so big that paging out and paging in
a significant fraction of that just takes too long. I have not tried
it on SSDs (we configure without swap space these days), but when I
recently thought I would run a 100GB process on a 128GB machine, and
the process actually needed 200GB, I was glad that the OOM killer
killed the process without much ado instead of swapping it to the
SSDs.
- anton
gcc handles this just fine by putting the functions into the text
segment, and the array in the bss segment. By contrast, VFX does not
do this separation, and fails.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
gcc handles this just fine by putting the functions into the text
segment, and the array in the bss segment. By contrast, VFX does not
do this separation, and fails.
That seems like a traditional Forth approach, having code and data in
the same dictionary segment. Microcontroller Forths often have multiple segments (e.g. code goes in flash memory) but you switch segments
manually. I guess workstation Forths could use it too, some of the time.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
gcc handles this just fine by putting the functions into the text
segment, and the array in the bss segment. By contrast, VFX does not
do this separation, and fails.
That seems like a traditional Forth approach, having code and data in
the same dictionary segment.
There was discussion BUFFER: might have a role but ISTM this was more
'after the fact' of its inclusion.
Paul Rubin <no.e...@nospam.invalid> writes:[..]
That seems like a traditional Forth approach, having code and data inCertainly. But not an important one. Some Forth systems have
the same dictionary segment.
separated headers (also untraditional), some separated uninitialized
RAM (also untraditional); separating native code should be no problem.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Ramanujan's taxi
<http://www.complang.tuwien.ac.at/forth/programs/taxi.fs> will take a
lot of dictionary memory, depending on the parameters; e.g., for the
taxi numbers up to 9000 development Gforth takes 2.7GB....
I've gotta say this trick of using a text interpreter wordlist as a
general purpose lookup structure still makes me cringe. It would be
nice to have a hash table library that you could ALLOCATE space for.
In this particular case, if I understand the algorithm, there are only >9000*9000/2 numbers to consider, which is about 4e7. For each pair
(i,j) you would compute s=i**3+j**3 and check whether you had already
seen another pair with that sum. So you would need a bit vector of
about 5MB, not anything like 2.7GB. Whenever you find a match, you
would check that s for ways of expressing it as the sum of two cubes,
which can be done quickly enough in various straightforward ways.
albert@cherry.(none) (albert) writes:
In article <2022Aug1.122649@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Small systems are affected by slowdowns from code/data mixing as much
as large or homungous systems are. Let's see how things turn out in >>>various systems:
I can assemble a version of ciforth where all code is collated in a
small space. With a indirect threading Forth the rest is data.
Would that worth while to try, even only as an experiment?
I expect similar results as for gforth-itc, which I insert below.
If you currently have the primitives interspersed with data that is
written frequently, you may suffer slowdowns (and for the Pentium and
K6, even for data that is read or written frequently). It will not be
for the code that I used for the native-code systems, but serious
slowdowns have occured due to this problem in native-code systems;
e.g. bigForth is slower than gforth-0.7 by a factor of 5 due to this
problem. And if your system has this problem, I would not be
surprised if there is a workload where it actually consumes a
significant amount of time.
- anton
No problem to implement, but once I had it, I'd certainly start making
use of the fact that data is contiguous. E.g., record names can be done
very elegantly, and matrices would be just a collection of named vectors.
Not sure that would help portability :--)
Or you could have a byte array of 2 *9000^2 counters, 200 mbyte.
These contain the number of time the index appears as a sum of cubes.
Marcel Hendrix <m...@iae.nl> writes:
No problem to implement, but once I had it, I'd certainly start makingcode.
use of the fact that data is contiguous. E.g., record names can be done >very elegantly, and matrices would be just a collection of named vectors. Sounds to me like you are thinking of separated headers, not separated
albert@cherry.(none) (albert) writes:
Or you could have a byte array of 2 *9000^2 counters, 200 mbyte.
These contain the number of time the index appears as a sum of cubes.
I'm missing something there, I just used an array of 9000^2 64-bit ints
and sorted them to find duplicates. Compiled with g++ -O it takes about
3 seconds on my laptop. It took a bit over 20 seconds without -O.
dxforth <dxforth@gmail.com> writes:
There was discussion BUFFER: might have a role but ISTM this was more >>'after the fact' of its inclusion.
That actually was the key point for standardizing BUFFER:. Proponents
argued that the Forth-94 alternative
create <name> <size> allot
requires initialized RAM (i.e., more ROM space in their cross-compiled systems for keeping the initial RAM contents), while with BUFFER: the
RAM is uninitialized and does not need space in ROM.
But for desktop VFX64, BUFFER: seems to use the same memory as ALLOT;
When I changed the 2GB ALLOT into a 2GB BUFFER: in my example, VFX
5.11 still crashes.
I've gotta say this trick of using a text interpreter wordlist as a
general purpose lookup structure still makes me cringe.
It would be
nice to have a hash table library that you could ALLOCATE space for.
I'm missing something there, I just used an array of 9000^2 64-bit ints
and sorted them to find duplicates. Compiled with g++ -O it takes about
3 seconds on my laptop.
s cycles instructions
3.35 16_039_014_129 10_085_237_291 gforth-fast 9000 taxi2.4th
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
s cycles instructions
3.35 16_039_014_129 10_085_237_291 gforth-fast 9000 taxi2.4th
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
Wow, that is basically as fast as g++ -O2 with a stdlib vector and the library sort function, which seemed simpler to me than using a hash
table. It uses around 300MB. Most of the cpu time is spent sorting.
I'd be interested to know how much memory the hash table uses.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
s cycles instructions
3.35 16_039_014_129 10_085_237_291 gforth-fast 9000 taxi2.4th
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
Wow, that is basically as fast as g++ -O2 with a stdlib vector and the >library sort function, which seemed simpler to me than using a hash
table.
It uses around 300MB. Most of the cpu time is spent sorting.
I'd be interested to know how much memory the hash table uses.
#include <vector>
#include <stdint.h>
#include <iostream>
#include <algorithm>
typedef int64_t xint;
const xint nmax = 9000;
int main() {
std::vector<xint> v;
xint i,j;
for (i = 1; i < nmax; i++)
for (j = i; j < nmax; j++)
v.push_back(i*i*i + j*j*j);
std::sort(v.begin(), v.end());
int dups = 0;
for (i = 0; i < v.size() - 2; i++) {
if (v[i] == v[i+1]) {
std::cout << "dup " << v[i] << "\n";
dups++;
}
}
std::cout << dups << " dups\n";
}
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
1.70 8_053_294_428 10_664_441_167 a.out (taxi.cc binary)
But taxi2.4th does more than taxi.cc: It does not just output
the sum, but also the constituent numbers.
One could store the constituent numbers instead of the sum,
That's substantially shorter than https://rosettacode.org/wiki/Taxicab_numbers#C.2B.2B
but then the two programs do different things.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
1.70 8_053_294_428 10_664_441_167 a.out (taxi.cc binary)
Nice.
But taxi2.4th does more than taxi.cc: It does not just output
the sum, but also the constituent numbers.
Yes, I thought about storing those, but it is easy enough to recover the constituent numbers given the sum. Given the sum s, you just find all
the k <- [1...9000] where t=s-k**3 is itself a cube. There are at most cuberoot(2 * 9000**2) = 545 such cubes, so you can just precompute a
hash table of 545 entries, and then check each t with a single lookup.
I didn't bother implementing that but might do so.
In fact maybe it's enough to check all the sums of two cubes that way by "brute force" rather than messing with large hash tables or sorted
lists. I might try that too.
One could store the constituent numbers instead of the sum,
I don't quite understand the reasoning about cache misses but it's ok, I
can think about it some more. I do expect that the sorting method had
good cache locality since it just grows a vector and then uses something
like quicksort.
Hmm, AFAICS for each sum you need to iterate over k. Assuming
limit on number N (in our case 9000) and M sums we get complexity
N*M for this step. M is 35760, significantly larger than N.
You mean generate sums and then check for alternative representaion?
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
1.56 7_353_893_755 2_627_580_253 vfx64 9000 taxi2.4th
1.70 8_053_294_428 10_664_441_167 a.out (taxi.cc binary)
Nice.
But taxi2.4th does more than taxi.cc: It does not just output
the sum, but also the constituent numbers.
Yes, I thought about storing those, but it is easy enough to recover the >constituent numbers given the sum. Given the sum s, you just find all
the k <- [1...9000] where t=s-k**3 is itself a cube. There are at most >cuberoot(2 * 9000**2) = 545 such cubes, so you can just precompute a
hash table of 545 entries, and then check each t with a single lookup.
One could store the constituent numbers instead of the sum,
I don't quite understand the reasoning about cache misses
I do expect that the sorting method had
good cache locality since it just grows a vector and then uses something
like quicksort.
I don't follow your reasoning. Where is the 2 * 9000**2 coming from?
It seems to me that there are up to 9000 cube roots (because there are
9000 possible summands), but of course you can also look them up in a
hash table. But overall the code is going to become quite a bit larger.
You can also store i,j instead of the sum, and do the sort with a
comparison that compares i^3+j^3 (C++ sort can do that, no?).
sorting requires about 1G comparisons (or is it half of that? Anyway, significantly more).
I don't follow your reasoning. Where is the 2 * 9000**2 coming from?
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
I don't follow your reasoning. Where is the 2 * 9000**2 coming from?
It occurs to me also that taxi.cc doesn't quite work, because it doesn't >detect taxicab numbers n=a^3+b^3=c^3+d^3 where a,b < 9000 but c or d
is >= 9000.
Note 1: I pack one number and sum of cubes into a word. From
then one can reconstruct the second number.
For
heapsort one really should use locals, it would be more readible
and probably more efficient (with old gforth version using
locals is about 20% faster).
antispam@math.uni.wroc.pl writes:
For
heapsort one really should use locals, it would be more readible
and probably more efficient (with old gforth version using
locals is about 20% faster).
Could you publish your locals version?
I have thought about using the heap as a priority queue for the taxi
problem, as follows:
for i in 2...9000 do
insert-into-heap(i, 1, sumcubes(i,1)) (sorted by the sumcubes element) old_t=0
while heap not empty do
extract-smallest(i, j, t)
if t=oldt
report found taxi number
j:=j+1
if j<i
insert-into-heap(i,j, sumcubes(i,j));
The heap should only contain 9000 numbers, rather than 9000^2/2,
reducing the number of inner loop iterations by a factor of 2,
and,
more importantly, these numbers fit in the L2 cache and the data-cache
hit rate should not be too bad, either. And of course it means that
we need much less memory.
Unfortunately, it's unclear to me how to get from your SIFT word to insert-into-heap and extract-smallest.
We have already talked about the fact that VFX Forth does not support
64-bit memory space with dignity.
Zombie (Anton) pressed Stephen to fix it, instead of bypassing the problem. >(I suggest a nickname for Albert van der Horst: Pony, because he wrote on
his website: "I have this Miami Vice poney tail".)
Then it turned out that Pony's Ciforth can't save 64-bit memory space as a >turnkey application. (Where are you Pony, I'm worried about you!)
It looks like these problems will not be resolved by the 1948 age
generation group (1948 is a very good year, like wine!). Too much
marketing.
Since iForth is not downloadable, there is only one more 64-bit Forth >available for the general user: Zombie's Gforth.
So, Zombie, is it possible to save a standalone turnkey application in >Gforth, or do we people of the world don't have any 64-bit Forth that can >correctly write a multi-gigabyte 64-bit turnkey application?
Let us make it clear that saving a data file (you'd've called it Image
Files) that needs an additional Forth to load is not a standalone turnkey >application.
It is actually a defect in WRITE-FILE. I did not head the warning
that the system call could write less bytes than requested.
So ciforth's WRITE-FILE is not able to write more than 2 Gbyte at once.
There is an ugly fix.
Before loading SAVE-SYSTEM you could revector PUT-FILE like so:
\ -------------------- 8< ------------------------------------
: WRITE-FILE1 BEGIN
DUP >R ROT DUP >R ROT DUP >R .S 1 XOS DUP 0 MIN THROW R>
SWAP - DUP WHILE R> OVER + SWAP R> REPEAT RDROP RDROP ;
: PUT-FILE1
0 CREATE-FILE THROW DUP >R WRITE-FILE1 THROW R> CLOSE-FILE THROW
;
'PUT-FILE1 'PUT-FILE 3 CELLS MOVE
\ BM 4,000,000,000 "hoax" PUT-FILE
\ .S
\ -------------------- 8< ------------------------------------
Hello Pony! I am very happy to see you in good condition!Did it occur to you it is holiday season?
Where have you been all this time? I was worried about you, that something happened to you. You disappeared so suddenly.
It's not the same here without you.
I wanted to download lina for Debian from >https://home.hccnet.nl/a.w.m.van.der.horst/lina.html
in debian package form and this is where the first problems appeared. I saw 404 Not Found.
I downloaded an archive from somewhere else. I started lina, tested 1 2 + .
It works but then I didn't know what else could be done in Ciforth.
I read the manual and even saw the word list on the green background on the internet.
Still nothing would work, not even work bye
I've seen here before that you are using a strange WANT
You could prepare a special rich-featured Ciforth release for dumbs,
with all your extras and especially a working disassembler.
I will be very happy to test it.
Is your Ciforth at all a native Forth?
lina64 -aIt looks like you are implementing the main data stack called the parameter stack using the CPU stack.
WANT ASSEMBLERi86
CODE aap POP, AX| NEXT, END-CODE
1 2 3 .S aap .S
S[ 1 2 3 ]
S[ 1 2 ] OK
Hello Pony!
You wrote:
lina64 -aIt looks like you are implementing the main data stack called the parameter stack using the CPU stack.
WANT ASSEMBLERi86
CODE aap POP, AX| NEXT, END-CODE
1 2 3 .S aap .S
S[ 1 2 3 ]
S[ 1 2 ] OK
Since I am unfamiliar with such an idea, I ask is it really so?
The typical solution in native Forths is that the return stack is implemented with the rsp register. This is natural as
the processor places the return addresses of the called words there.
Native Forths usually implement the data stack using the rbp register.
Where is your return stack then?
I need this information because I plan to write Mouse's Ugly Heapsort word in the x64 assembler for all of you and I will
have to propose the most universal interface possible between all your Forths and the x64 assembler.
Why not try something like this. This guy's brilliant. https://youtu.be/7r83N3c2kPw
Why not try something like this. This guy's brilliant.Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote:
Why not try something like this. This guy's brilliant.Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entire
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
On 31/08/2022 6:57 am, Hans Bezemer wrote:
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote:
Why not try something like this. This guy's brilliant.Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entireIt must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
On 31/08/2022 6:57 am, Hans Bezemer wrote:BTW some of these guys type so fast. I saw of guy on a video last week, immensely
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote:
Why not try something like this. This guy's brilliant.Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entireIt must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
On Wednesday, August 31, 2022 at 10:10:50 AM UTC+10, dxforth wrote:
On 31/08/2022 6:57 am, Hans Bezemer wrote:
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote: >>>> Why not try something like this. This guy's brilliant.It must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entire
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
The guy is energetic and exciting, that's how he does it. People like energetic clowns (within reason).
The song with him dancing with his Apple 2 was a classic. Maybe somebody could do one with
a 144. :)
On Wednesday, August 31, 2022 at 10:10:50 AM UTC+10, dxforth wrote:Ah, that's the point, this guy was more about entertaining and training the audience rather
On 31/08/2022 6:57 am, Hans Bezemer wrote:
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote:
Why not try something like this. This guy's brilliant.Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
BTW some of these guys type so fast. I saw of guy on a video last week, immenselyFor starters - it's MUCH too long to my taste. And I don't like a guy typing in an entireIt must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
faster. It might have been an part of an instructional video on advanced Commodore 64
graphics coding, or some sort of embedded stuff. But, like Hans, I'm not interested in
watching that, but this video was interesting because he could pull it off, and jumped and
train people by reflecting on the thinking of the process, is a racy jump cut kind of style.
Wayne morellini <waynemorellini@gmail.com> writes:
Why not try something like this. This guy's brilliant.
https://youtu.be/7r83N3c2kPw
I only watched a few minutes but that looks pretty good. I liked the
song at the beginning. I started wondering how well a BASIC style line-number editor would work for Forth, and then remembered Forth
usually used screen editors. That made me realize BASIC is even older
than Forth. The line number editor came from the days when BASIC was normally used on printing terminals. Specifically Teletype Model 33's
or maybe even older models. Good times.
On 31/08/2022 11:50 am, Wayne morellini wrote:Clowning around, funning around, or being over the top, loud, fast, classically the sort of impressions
On Wednesday, August 31, 2022 at 10:10:50 AM UTC+10, dxforth wrote:
On 31/08/2022 6:57 am, Hans Bezemer wrote:
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote: >>>> Why not try something like this. This guy's brilliant.It must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entire
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
The guy is energetic and exciting, that's how he does it. People like energetic clowns (within reason).Ah - so he was trying to be a clown. That requires talent.
The song with him dancing with his Apple 2 was a classic. Maybe somebody could do one with
a 144. :)
On 31/08/2022 11:50 am, Wayne morellini wrote:
On Wednesday, August 31, 2022 at 10:10:50 AM UTC+10, dxforth wrote:
On 31/08/2022 6:57 am, Hans Bezemer wrote:
On Tuesday, August 30, 2022 at 7:44:35 PM UTC+2, Wayne morellini wrote: >>>> Why not try something like this. This guy's brilliant.It must be a 'Big Brother' thing. Who'd have thought there'd be an audience for
Well, the best way I can explain that I'm not doing his stuff is that I don't like it.
For starters - it's MUCH too long to my taste. And I don't like a guy typing in an entire
program line by line. That's just boring. I don't like videos that entirely consist of
terminal sessions anyway.
watching people making and correcting mistakes? Wouldn't have happened in 1981 :)
The guy is energetic and exciting, that's how he does it. People like energetic clowns (within reason).Ah - so he was trying to be a clown. That requires talent.
The song with him dancing with his Apple 2 was a classic. Maybe somebody could do one with
a 144. :)
Clowning around, funning around, or being over the top, loud, fast, classically the sort of impressionsIt's the kind of Benny Hill humor that works for the Germans. But not me. I loved all my computers till
used of American soldiers in world war 2. The English and Northern Europeans will probably get it.
On Wednesday, August 31, 2022 at 7:38:54 AM UTC+2, Wayne morellini wrote:
Clowning around, funning around, or being over the top, loud, fast, classically the sort of impressions
used of American soldiers in world war 2. The English and Northern Europeans will probably get it.
It's the kind of Benny Hill humor that works for the Germans. But not me. I loved all my computers till
the caps blew, even gave 'em names - but I never danced around with them or kissed them.
Wayne morellini <waynemorellini@gmail.com> writes:
Why not try something like this. This guy's brilliant.
https://youtu.be/7r83N3c2kPw
I only watched a few minutes but that looks pretty good. I liked the
song at the beginning. I started wondering how well a BASIC style
line-number editor would work for Forth, and then remembered Forth
usually used screen editors. That made me realize BASIC is even older
than Forth. The line number editor came from the days when BASIC was
normally used on printing terminals. Specifically Teletype Model 33's
or maybe even older models. Good times.
IBM expected customers to use a line editor in 1981 - never mind the
machine had full-screen video capability :(
It might have been an part of an instructional video on advanced Commodore 64
graphics coding, or some sort of embedded stuff.
What's the sense of creating videos about =E2=80=9Eadvanced Commodore 64 gr= >aphics coding=E2=80=9D,
when it's perfectly possible to do much more interesting things with TCL/Tk=
on your
Windows/Linux/Mac machine =E2=80=94 and using much more sensible language t= >han CBM BASIC?
I started wondering how well a BASIC style
line-number editor would work for Forth, and then remembered Forth
usually used screen editors. That made me realize BASIC is even older
than Forth. The line number editor came from the days when BASIC was >normally used on printing terminals.
On 31/08/2022 6:24 pm, Hans Bezemer wrote:
On Wednesday, August 31, 2022 at 7:38:54 AM UTC+2, Wayne morellini wrote:
Clowning around, funning around, or being over the top, loud, fast, classically the sort of impressions
used of American soldiers in world war 2. The English and Northern Europeans will probably get it.
It's the kind of Benny Hill humor that works for the Germans. But not me. I loved all my computers till
the caps blew, even gave 'em names - but I never danced around with them or kissed them.
The English got their humour from programming those ZX things, having
been told it was 'a computer' :)
In article <temkg4$17is$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:Orange was also available.
On 31/08/2022 4:29 am, Paul Rubin wrote:
Wayne morellini <waynemorellini@gmail.com> writes:
Why not try something like this. This guy's brilliant.
https://youtu.be/7r83N3c2kPw
I only watched a few minutes but that looks pretty good. I liked the
song at the beginning. I started wondering how well a BASIC style
line-number editor would work for Forth, and then remembered Forth
usually used screen editors. That made me realize BASIC is even older
than Forth. The line number editor came from the days when BASIC was
normally used on printing terminals. Specifically Teletype Model 33's
or maybe even older models. Good times.
IBM expected customers to use a line editor in 1981 - never mind the >machine had full-screen video capability :(
I developed FORTRAN programs for Shell on the IBM 360, using a 24x80
terminal green monochrome terminal. Maybe I (Shell) was a priviledged
customer (AD 1979/1980).
I think the attraction of retrocomputing is that the old computers are easier to understand, and their limits provide a manageable challenge.
I think the attraction of retrocomputing is that the old computers are
easier to understand, and their limits provide a manageable challenge.
FOR YOU — I mean the real professional — they are easier to understand (their FW, their electronics etc.). But the average user will have even more trouble with them than with any modern — very advanced and complicated — machine: „what do I click”? „Where is anything clickable”? „Wait… where is the
mouse”?!
As for programming: have a look at modest TCL and Tk 8.4.20 packages — they do contain fine docs and demo (started with "sh widget") showing what can
be done with this and displaying source code.
TCL is somewhat Pascal/C-like — just easier, extensible and interpreted. Ideal
for novices (that dislike Forth). And having many extensions available, with Tcllib on the first place.
Paul Rubin <no.email@nospam.invalid> writes:
I started wondering how well a BASIC style
line-number editor would work for Forth, and then remembered Forth
usually used screen editors. That made me realize BASIC is even older
than Forth. The line number editor came from the days when BASIC was
normally used on printing terminals.
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
BASIC's use of line numbers is brilliant: They serve double duty as
editing interface and for control flow.
On Wednesday, August 31, 2022 at 7:38:54 AM UTC+2, Wayne morellini wrote:
Clowning around, funning around, or being over the top, loud, fast, classically the sort of impressionsIt's the kind of Benny Hill humor that works for the Germans. But not me. I loved all my computers till
used of American soldiers in world war 2. The English and Northern Europeans will probably get it.
the caps blew, even gave 'em names - but I never danced around with them or kissed them.
Hans Bezemer
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
It might have been an part of an instructional video on advanced Commodore 64What's the sense of creating videos about „advanced Commodore 64 graphics coding”,
graphics coding, or some sort of embedded stuff.
when it's perfectly possible to do much more interesting things with TCL/Tk on your
Windows/Linux/Mac machine — and using much more sensible language than CBM BASIC?
One can create graphics application easily, comfortably, in the language as extensible as
Forth — and directly on the machines they are using right now; no need to buy retro-hardware
neither to use any emulators.
(and I write this as Commodore user since late 1984)
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
I guess I'm not familiar with it. The screen editors I've seen used
cursor keys etc. They were written for 16 lins x 64 chars "screens".
AFAIR I never tried to actually use one though.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
I guess I'm not familiar with it. The screen editors I've seen used
cursor keys etc.
Anton Ertl wrote:
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
I guess I'm not familiar with it. The screen editors I've seen used
cursor keys etc. They were written for 16 lins x 64 chars "screens".
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
I guess I'm not familiar with it. The screen editors I've seen used
cursor keys etc. They were written for 16 lins x 64 chars "screens".
AFAIR I never tried to actually use one though.
I can only wonder how young folk will fare in a world they can no longer understand nor control.
It's a hobby industry, and they use assembler for this. The guy charges a packet for those videos.
If people want to do that instead of postage stamp collection and buying bikes or cars,
that's up to them. Not much harm done.
Paul Rubin wrote:
Anton Ertl wrote:
"Screen editor" is ambiguous in Forth. The classic Forth screen
editor uses an interface that is designed for a paper terminal.
I guess I'm not familiar with it. The screen editors I've seen used
cursor keys etc. They were written for 16 lins x 64 chars "screens".
That's the screen format, but it doesn't necessarily have to display on
a screen.
I have a day job programming Forth and we use screen format source code.
But we use an Emacs mode that displays a regular text file in 16-line
blocks, and adds command for screen-based editing. Regular text files integrate better with other tooling like git. A small program converts
the files into the 1K blocks Forth wants.
I can only wonder how young folk will fare in a world they can no longer understand nor control.
They are going to rely on Siri and Alexa.
For a professional retrocomputing has little appeal, because the
paying customers have recent hardware.
I think the attraction of retrocomputing is that the old computers are=20
easier to understand, and their limits provide a manageable challenge.
FOR YOU =E2=80=94 I mean the real professional =E2=80=94 they are easier to=
understand
(their FW, their electronics etc.).
We've made technology into our master. Today's systems are so complex that even the gurus can't trace the source of a fault. And faults there are aplenty.
If a day goes by where I don't have to consult google for a solution to a problem caused by Windows, MAIL or some other great life-enhancing APP, then I'm feeling lucky for having dodged another bullet. I can only wonder how young folk will fare in a world they can no longer understand nor control.
Fig-Forth Installation Manual included source for a line-basedThat's about the same editor that still resides in 4tH. Something I
editor to get you up and running.
I think it's the fun of doing something elaborate with very few resources. I get a kick out of that
when doing fixed point calculation in my own uBasic/4tH. Or cramming an entire structure using
bitfields in a 32 bit signed integer, so I can do a 3D adventure game with a single 256 element
array.
Zbig <zbigniew2011@gmail.com> writes:
I think the attraction of retrocomputing is that the old computers are=20 >>> easier to understand, and their limits provide a manageable challenge.
FOR YOU =E2=80=94 I mean the real professional =E2=80=94 they are easier to= >> understand
(their FW, their electronics etc.).
For a professional retrocomputing has little appeal, because the
paying customers have recent hardware.
Retrocomputing is an amateur thing. Not all amateur programmers are
into retrocomputing, but certainly the proportion of amateurs in retrocomputing (compared to up-to-date computing) is higher than in
the professional realm.
I think it's the fun of doing something elaborate with very few resources. I get a kick out of thatIt might have been an part of an instructional video on advanced Commodore 64What's the sense of creating videos about „advanced Commodore 64 graphics coding”,
graphics coding, or some sort of embedded stuff.
when it's perfectly possible to do much more interesting things with TCL/Tk on your
Windows/Linux/Mac machine — and using much more sensible language than CBM BASIC?
One can create graphics application easily, comfortably, in the language as extensible as
Forth — and directly on the machines they are using right now; no need to buy retro-hardware
neither to use any emulators.
Not sure how they do it, but I've encountered middle-aged professionals
who are into retrocomputing as a hobby. For them the 80's is still
within memory though they must have been quite young at the time. It
would have been magic for them then but now they're in a position to >understand how it worked.
I don't know how young they would have been at the time, but I got a
C64 in 1982 at 15; some months later the book "64 intern" appeared
which contained lots of information about the hardware and
programming, and I could then explore the C64 down to the metal.
These days I don't have a desire to write software for this hardware.
Why do you develop for the 8086 (and 8080?)?
On Thursday, September 1, 2022 at 6:53:55 PM UTC+2, Anton Ertl wrote:
[..]
I don't know how young they would have been at the time, but I got a
C64 in 1982 at 15; some months later the book "64 intern" appeared
which contained lots of information about the hardware and
programming, and I could then explore the C64 down to the metal.
These days I don't have a desire to write software for this hardware.
Why do you develop for the 8086 (and 8080?)?
I'm older and the fascination started after I left the university.
In 1973 Dijkstra had just left TU/e and the high-priests didn't
let us near the Burroughs 7700 -- we had to toil on an 8008 :--)
I never felt sentimental about any of my computers, not even the
ones that I built from scratch (a Z80-based from Elektor and the
M68000 kit from C't). I guess it has to do with the age when you
first encounter them.
No IT professionals in white coats here - just young, very clever, enthusiastic amateurs. As for the 8008 with its quirky limited
architecture, it's amazing what they managed to get that chip to do.
Today it's all spoon-fed and what's produced is, well, bland. I've
seen no advancement (software-wise) from what was available in 2000.
In some ways I think it's gone backwards.
On Friday, September 2, 2022 at 12:02:20 AM UTC+2, dxforth wrote:
[..]
No IT professionals in white coats here - just young, very clever,
enthusiastic amateurs. As for the 8008 with its quirky limited
architecture, it's amazing what they managed to get that chip to do.
Today it's all spoon-fed and what's produced is, well, bland. I've
seen no advancement (software-wise) from what was available in 2000.
In some ways I think it's gone backwards.
The percentage of really smart people stays the same. They're not
working on the things we know already or that we find valuable.
I don't bemoan realThere is a very nice and detailed story of it in "The barbarians led by
innovation - which isn't about control or getting rich. True
innovation is a disruptor. It threatens mega corporations who are
all about control. If they can't buy it out, they'll try to bankrupt
it. At least for a while as none have managed to stop human thought.
Can anyone explain to me why companies STILL use MS Office (instead
of LibreOffice) while most of the users don't even use a hair of its possibilities and are willing to pay a pretty bundle for it and go through all the hassle of licence management (which may be one of the most
complex parts of ITSM)?
Can anyone explain to me why companies STILL use MS Office (instead
of LibreOffice) while most of the users don't even use a hair of its possibilities and are willing to pay a pretty bundle for it and go through all the hassle of licence management (which may be one of the most
complex parts of ITSM)?
I know lots of companies that pay for the FULL package, just to avoid
these very disrupting licencing audits.
Hans Bezemer
I think it's the fun of doing something elaborate with very few resources. I get a kick out of thatThat's different story — I referred to the assumptions of „advanced graphics coding”.
when doing fixed point calculation in my own uBasic/4tH. Or cramming an entire structure using
bitfields in a 32 bit signed integer, so I can do a 3D adventure game with a single 256 element
array.
Curious why your Forth "wants" blocks - is it not a hosted system?
It's a hobby industry, and they use assembler for this. The guy charges a packet for those videos.Assembler-related videos are for different audience than the one about BASIC. I can see that reading C-64 forums; not that often the guys that are tinkering
If people want to do that instead of postage stamp collection and buying bikes or cars,
that's up to them. Not much harm done.
with that hopeless CBM BASIC (created by (in)famous Bill, BTW) are switching to assembler. They even seldom switch to better BASICs, available for C-64 (not to mention more sensible languages, like Forth or Pascal).
Actually the best BASIC available for 8-bit machines was... Comal-80.
Anybody know?
Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.
Having lead the Canadian arm of an American fortune 500 company it's simple priority management Hans.Yeah - as if you're the first one telling me that story. But if you add to that the effort
In companies that generate real money these costs are trivial, senior managers don't have to explain WHY they spent the money and it's tax deductible.
There are more important things to worry about in that realm.
(Making more money comes to mind. You know that pursuit of infinite growth thing) :)
Sure, not all managers can be Elon Musk, but most even lack even the most basic skills for
leadership. They buy all the books, follow all the $1000 a day courses - but they will never
ever be leaders.
If you want to be a leader, just go your way. Then look back. If no one is following you,
then you know.
Hans Bezemer
On Friday, September 2, 2022 at 3:15:24 PM UTC+2, Brian Fox wrote:
Having lead the Canadian arm of an American fortune 500 company it's simple priority management Hans.Yeah - as if you're the first one telling me that story. But if you add to that the effort
In companies that generate real money these costs are trivial, senior managers don't have to explain WHY they spent the money and it's tax deductible.
There are more important things to worry about in that realm.
(Making more money comes to mind. You know that pursuit of infinite growth thing) :)
in lost business days, the extra amount of workforce involved in it all - and all the hardware
and software you have to invest to get it all running, it adds up to some pretty nice sum.
And I know it, because I was involved in several projects concerning this, calculating the
total cost (and total savings) involved. I tell you what the real reason is: fear - or better:
uncertainty. Most of these petty managers can't handle a total redesign of their environment -
whatever savings or other benefits it brings on the long run. They're too chicken to have
such a bold vision, because they're risk avoiders - and frankly, lack every bit of vision.
Sure, not all managers can be Elon Musk, but most even lack even the most basic skills for
leadership. They buy all the books, follow all the $1000 a day courses - but they will never
ever be leaders.
If you want to be a leader, just go your way. Then look back. If no one is following you,
then you know.
Hans Bezemer
dxforth wrote:
Curious why your Forth "wants" blocks - is it not a hosted system?
It's this one:
https://github.com/ablevm/able-forth
This Forth is hosted, but it doesn't have any file I/O, so all data has
to be inside the memory image when it starts up. There's a bootstrap
image with the basic system, but additional code is compiled by putting source screen blocks into the image and then loading it.
One benefit of doing this is security. When Forth is up and running, no
code can access or wreak havoc with the host file system.
No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Thanks. I knew there had to be an explanation :) In my case 'I' wanted screens (over text).
I can' t disagree with you there. Due to my unusual career path, I didn't quite match
the thinking of the $1000/day course people.
I was accused of "innovation" which is kind of slur in some corporate circles. :)
To me it seemed like "common sense".
I know our team got results and some things went international ...
I never looked back much. ;-)
This Forth is hosted, but it doesn't have any file I/O, so all data has
to be inside the memory image when it starts up. There's a bootstrap
image with the basic system, but additional code is compiled by putting >source screen blocks into the image and then loading it.
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.
... I fail to see the advantage of using screens rather
than newline-separated lines.
I think it's interesting. It certainly encourages the good habit of
keeping definitions to be shorter than 16 lines!
http://sources.vsta.org/forthos/fs.html
Oh, yeah — „or something”; how precisely and accurately described.No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.What are you taking about. They did a further then they did a basic, the basic was eventually
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Sorry, I didn't say the two ever were connected
Actually the best BASIC available for 8-bit machines was... Comal-80.
Is it as good as white lightning, they did after their Firth, later sold as laser basic
by Ocean or somebody.
Oh, yeah — „or something”; how precisely and accurately described.No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.What are you taking about. They did a further then they did a basic, the basic was eventually
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Yes, you did:Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Sorry, I didn't say the two ever were connected
Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning, they did after their Firth, later sold as laser basic
by Ocean or somebody.
If you weren't referring to Comal-80 — which I was talking about — then what actually
you were referring to?
So again: „use Google, Luke”.
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.
Oh, yeah — „or something”; how precisely and accurately described.No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.What are you taking about. They did a further then they did a basic, the basic was eventually
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Yes, you did:Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Sorry, I didn't say the two ever were connected
Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning, they did after their Firth, later sold as laser basic
by Ocean or somebody.
If you weren't referring to Comal-80 — which I was talking about — then what actually
you were referring to?
So again: „use Google, Luke”.
Lars Brinkhoff <lars.spam@nocrew.org> writes:
I think it's interesting. It certainly encourages the good habit of
keeping definitions to be shorter than 16 lines!
I thought the 64 char lines were also somewhat constraining, especially
if you write stack comments inside definitions. I guess the workaround
was shadow screens, so you sort of had a comment line for each program
line.
I think someone did a Forth a while back where screens were 2K bytes
instead of 1K. So each screen had 24 lines of 80 chars per line, plus a title line, plus 48 bytes used for metadata of some sort.
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Well, it was more accurate, it was white lightning basic they did after the original white lightning forth, then
they did laser basic by Ocean, as I said.
On Sunday, September 4, 2022 at 4:45:45 AM UTC+10, Zbig wrote:
Oh, yeah — „or something”; how precisely and accurately described.No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.What are you taking about. They did a further then they did a basic, the basic was eventually
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Yes, you did:Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Sorry, I didn't say the two ever were connected
Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning, they did after their Firth, later sold as laser basic
by Ocean or somebody.
If you weren't referring to Comal-80 — which I was talking about — then what actually
you were referring to?
So again: „use Google, Luke”.Please stop stirring. Anybody can see I'm not calling itwhitelighting and comparing
it to itself, instead of asking how it compares to a second product. If you are saying that
Comal-80 is a newer version of the same product (still a second or third product) that's better,
than say it, rather than trying to act smart.
Lars Brinkhoff <lars.spam@nocrew.org> writes:
This Forth is hosted, but it doesn't have any file I/O, so all data has
to be inside the memory image when it starts up. There's a bootstrap
image with the basic system, but additional code is compiled by putting >>source screen blocks into the image and then loading it.
Even (or especially) with the source code loaded into memory as
read-only code, I fail to see the advantage of using screens rather
than newline-separated lines. The Forth-side processing may be a
little simpler, but that's balanced by having to write a converter and
always converting the code before building the image.
- antonGroetjes Albert
My screen are simple 1K byte files.
I like the property that screens provide a means to break code in
neat little packets.
Sacrificing 1 in 64 characters for a line break is not a big deal.
On 4/09/2022 4:38 am, Paul Rubin wrote:
Lars Brinkhoff <lars...@nocrew.org> writes:
I think it's interesting. It certainly encourages the good habit of
keeping definitions to be shorter than 16 lines!
I thought the 64 char lines were also somewhat constraining, especially
if you write stack comments inside definitions. I guess the workaround
was shadow screens, so you sort of had a comment line for each program line.
I think someone did a Forth a while back where screens were 2K bytes instead of 1K. So each screen had 24 lines of 80 chars per line, plus a title line, plus 48 bytes used for metadata of some sort.Screens are not the problem; it's whether you hate them.
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Obviously you have no idea what are you talking about.Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Well, it was more accurate, it was white lightning basic they did after the original white lightning forth, then
they did laser basic by Ocean, as I said.
„White Lightning” and „Basic Lightning” were two completely different products.
niedziela, 4 września 2022 o 05:57:24 UTC+2 Wayne morellini napisał(a):
On Sunday, September 4, 2022 at 4:45:45 AM UTC+10, Zbig wrote:
Oh, yeah — „or something”; how precisely and accurately described.No, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.What are you taking about. They did a further then they did a basic, the basic was eventually
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
Yes, you did:Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Sorry, I didn't say the two ever were connected
Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning, they did after their Firth, later sold as laser basic
by Ocean or somebody.
If you weren't referring to Comal-80 — which I was talking about — then what actually
you were referring to?
Indeed „Anybody can see” for oneself — I don't need to copy-paste anything more.So again: „use Google, Luke”.Please stop stirring. Anybody can see I'm not calling itwhitelighting and comparing
it to itself, instead of asking how it compares to a second product. If you are saying thatRubbish.
Comal-80 is a newer version of the same product (still a second or third product) that's better,
than say it, rather than trying to act smart.
On Sunday, September 4, 2022 at 7:40:23 PM UTC+10, Zbig wrote:
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
I'm not the one who is acting such. If you think they used entirely different routines..Obviously you have no idea what are you talking about.Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Well, it was more accurate, it was white lightning basic they did after the original white lightning forth, then
they did laser basic by Ocean, as I said.
„White Lightning” and „Basic Lightning” were two completely different products.
It was a game development orientated platform. I doubt they didn't transfer optimised
Game code from one to another, which would be the heart link I metaphorically referred
to, but I note that useful idea in English doesn't transfer too well to all cultures.
„White Lightning” was Forth, while „Basic Lightning” was BASIC. Neither was related to Comal-80.Again, enough said, I never said differently, we can see.
niedziela, 4 września 2022 o 17:55:17 UTC+2 Wayne morellini napisał(a):
On Sunday, September 4, 2022 at 7:40:23 PM UTC+10, Zbig wrote:
Oh, yeah — „or something”; how precisely and accurately described.What are you taking about. They did a further then they did a basic, the basic was eventuallyNo, „White Lightning” is Forth („apples to oranges”), Comal-80 is Pascal-like BASIC.Actually the best BASIC available for 8-bit machines was... Comal-80.Is it as good as white lightning,
they did after their Firth, later sold as laser basic by Ocean or somebody.No, „they” didn't do it. Google for Comal-80 and you'll see.
called laser basic or something. I did look u the history to try and contact the old developers.
„White Lightning” was Forth, while „Basic Lightning” was BASIC. Neither was related to Comal-80.I'm not the one who is acting such. If you think they used entirely different routines..Obviously you have no idea what are you talking about.Comal-80 has no connection to White Lightning whatsoever — I told you: google for this, recall the facts.Well, it was more accurate, it was white lightning basic they did after the original white lightning forth, then
they did laser basic by Ocean, as I said.
„White Lightning” and „Basic Lightning” were two completely different products.
It was a game development orientated platform. I doubt they didn't transfer optimised
Game code from one to another, which would be the heart link I metaphorically referred
to, but I note that useful idea in English doesn't transfer too well to all cultures.
Actually, that is the wrong term. The fact they probably share the same game engine routines, is what I wasSure, you were just „using a metaphore”.„White Lightning” was Forth, while „Basic Lightning” was BASIC. Neither was related to Comal-80.Again, enough said, I never said differently, we can see.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
... I fail to see the advantage of using screens rather
than newline-separated lines.
Screen-oriented source didn't "click" with me until I used it along with >shadow screens for code comments.
Of course, this was in the context of
ForthOS, which embedded block source within a very simple, very resilient >filesystem.
I used screens for Forth on the C64 (so for ~10 years), with
40x25 screens...
no messy shifting of words between screens when some code
needed growing
Sure, in certain environments, such as the ones where Forth
originated, or the C64, and apparently also ForthOS, the
implementation simplicity of screen files outweighs the costs.
Sacrificing 1 in 64 characters for a line break is not a big deal.
In article <2022Sep3.185853@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Lars Brinkhoff <lars.spam@nocrew.org> writes:
This Forth is hosted, but it doesn't have any file I/O, so all data has
to be inside the memory image when it starts up. There's a bootstrap
image with the basic system, but additional code is compiled by putting
source screen blocks into the image and then loading it.
Even (or especially) with the source code loaded into memory as
read-only code, I fail to see the advantage of using screens rather
than newline-separated lines. The Forth-side processing may be a
little simpler, but that's balanced by having to write a converter and
always converting the code before building the image.
Then there is no advantage to "simpler" screens without line breaks.
My screen are simple 1K byte files.
I like the property that screens provide a means to break code in
neat little packets.
Sacrificing 1 in 64 characters for a line break is not a big deal.
A simple \ using PARSE works portably for this.
...
For other programming languages and in other settings I used newline-separated files for the source code, with the editors
available for that. They allowed more flexibility and were less
cumbersome: no messy shifting of words between screens when some code
needed growing; and I can have a word and the next one on the display
at a time, even if they would be on different screens in a
screen-based system.
So when I got a more modern OS below my Forth system, I switched to
using newline-separated files and never looked back.
I think someone did a Forth a while back where screens were 2K bytes
instead of 1K. So each screen had 24 lines of 80 chars per line, plus a title line, plus 48 bytes used for metadata of some sort.
My ForthOS? I used 4k; 2k for source, 2k for shadow (when used as
Forth source).
... As an unrelated question regarding your locals:
http://sources.vsta.org/forthos/scopes.html
Where were the locals stored? I.e. were they on a stack?
So when I got a more modern OS below my Forth system, I switched to
using newline-separated files and never looked back. And from what I
see on other hosted systems, it was the same for most others. This
also integrates better with the rest of the tools on these OSs, e.g.,
git and grep ...
On 04/09/2022 19:43, Anton Ertl wrote:
...
So when I got a more modern OS below my Forth system, I switched to
using newline-separated files and never looked back. And from what I
see on other hosted systems, it was the same for most others. This
also integrates better with the rest of the tools on these OSs, e.g.,
git and grep ...
Indeed, this.
Neither Reva nor 8th have had screens support, because both are OS-hosted and can rely on using normal file IO routines and normal files.
On 5/09/2022 2:14 pm, Ron AARON wrote:
On 04/09/2022 19:43, Anton Ertl wrote:
...
So when I got a more modern OS below my Forth system, I switched to
using newline-separated files and never looked back. And from what I
see on other hosted systems, it was the same for most others. This
also integrates better with the rest of the tools on these OSs, e.g.,
git and grep ...
Indeed, this.
Neither Reva nor 8th have had screens support, because both are
OS-hosted and can rely on using normal file IO routines and normal files.
OS-hosting doesn't automatically support text-based forth source. INCLUDE-FILE represents a layer on top of the basic OS functions.
So it comes down to the implementation whether it supports text or
block layers - or both. And that will be a matter of preference.
On 05/09/2022 9:08, dxforth wrote:
On 5/09/2022 2:14 pm, Ron AARON wrote:
On 04/09/2022 19:43, Anton Ertl wrote:
...
So when I got a more modern OS below my Forth system, I switched to
using newline-separated files and never looked back. And from what I >>>> see on other hosted systems, it was the same for most others. This
also integrates better with the rest of the tools on these OSs, e.g.,
git and grep ...
Indeed, this.
Neither Reva nor 8th have had screens support, because both are OS-hosted and can rely on using normal file IO routines and normal files.
OS-hosting doesn't automatically support text-based forth source.
INCLUDE-FILE represents a layer on top of the basic OS functions.
So it comes down to the implementation whether it supports text or
block layers - or both. And that will be a matter of preference.
Yes of course. The point is that using external tools (vim, grep, awk, etc) is useful and convenient, and much easier with normal OS files than with screens (depending on how screens are implemented).
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
I used screens for Forth on the C64 (so for ~10 years), with
40x25 screens...
Were the 40 char lines horribly constraining?
no messy shifting of words between screens when some code
needed growing
Would a typical approach be to split the growing screen into two, rather
than shifting code from one screen to some other existing one? Or was
disk space (such as on floppies) usually also scarce?
I saved an old Jonah Thomas post (originally from 2003 though I came
across it much later) that made an impression on me. A quote from it:
Blocks gave an integrated editor, and fast integrated compiling,
and a sort of paged virtual memory, and something you could easily
turn into a somewhat inferior database, etc. It wasn't the best
solution for very much but it gave an easy adequate solution for a
whole lot.
I've never used a blocks system but the above quote always made me
wonder what it was like.
I've played with the idea of a resident Forth using blocks on a modern
MCU, but I think it would be better to use files when there is enough >storage, or a cross-compiler when there is not.
I never used the blocks for data.I wrote a library for screen based (binary) strings - although I never used it for an application. Furthermore, I used screens for scripting the multitasking 4tH variant "4tsH". The advantage here was one can do I/O on screens in a single context.
I can't speak for the C64, but the crudely converted FIG editor was close to unusable on the ZX Spectrum - since that one had 32*22 lines. Which meantWere the 40 char lines horribly constraining?Not particularly. It was the display width of the C64. Of course, I
found the 80-wide screens (and later windows) on more capable machines preferable, but there is alwas some limit.
albert@cherry.(none) (albert) writes:
Sacrificing 1 in 64 characters for a line break is not a big deal.
At least in classical Forth you cannot continue on the first character
of the next line in a screen if you used the last character of the
previous line for a word; you need at least one space between words.
So even if you fill the screen with code, there is no memory advantage
to the screen (maybe for the last newline).
I, however, prefer to group code into lines to reflect the structure
of the code, which leads to some lines being much shorter than others.
In that setting, newline separation is more memory-efficient than the
fixed line length of screens.
I measured the memory overhead of screens using the example of ><http://git.savannah.gnu.org/cgit/gforth.git/plain/blocked.fb>, which
is written in a much more horizontal style than I tend to use:
[~/gforth:132645] gforth -e ': b>n ( c-addr u -- ) slurp-file ( c-addr1 u1 ) bounds ?do i 64 -trailing type cr 64 +loop ; s" blocked.fb" b>n bye' >blocked.fs
[~/gforth:132646] ls -l blocked.f*
-rw-r--r-- 1 anton users 4096 Oct 1 2020 blocked.fb
-rw-r--r-- 1 anton users 2629 Sep 4 19:39 blocked.fs
So even for this horizontal code, the memory advantage of
new-line-separated files is more than a factor of 1.5.
- anton--
Just because MASM requires external tools to compose and edit source,
it doesn't follow forth should. Apparently there are things called 'programmers editors' - which presumably means it would be unproductive
for me to continue using a regular editor. In fact I don't feel disadvantaged at all.
On Monday, September 5, 2022 at 10:38:41 AM UTC+2, Anton Ertl wrote:
I can't speak for the C64, but the crudely converted FIG editor was close to unusable on the ZX Spectrum - since that one had 32*22 lines. Which meantWere the 40 char lines horribly constraining?Not particularly. It was the display width of the C64. Of course, I
found the 80-wide screens (and later windows) on more capable machines
preferable, but there is alwas some limit.
the thing was scrolling off screen all the time.
It was NOT the fault of the editor itself, though. Once used on a standard 80*25
screen it was perfectly usable. I was busy interfacing a 64 chars driver with my ZX Spectrum Forth, but then the IBM PC came and I never finished it.
On 5/09/2022 7:34 pm, Hans Bezemer wrote:
On Monday, September 5, 2022 at 10:38:41 AM UTC+2, Anton Ertl wrote:
I can't speak for the C64, but the crudely converted FIG editor was close toWere the 40 char lines horribly constraining?Not particularly. It was the display width of the C64. Of course, I
found the 80-wide screens (and later windows) on more capable machines
preferable, but there is alwas some limit.
unusable on the ZX Spectrum - since that one had 32*22 lines. Which meant the thing was scrolling off screen all the time.
It was NOT the fault of the editor itself, though. Once used on a standard 80*25AFAIK it was more usual to have screens match the video properties of the machine. The VIC-20 presented challenges due to the limited display. One forth got around it with a scrolling 64x16 full-screen editor.
screen it was perfectly usable. I was busy interfacing a 64 chars driver with
my ZX Spectrum Forth, but then the IBM PC came and I never finished it.
On Tuesday, September 6, 2022 at 11:06:50 AM UTC+10, dxforth wrote:
On 5/09/2022 7:34 pm, Hans Bezemer wrote:
On Monday, September 5, 2022 at 10:38:41 AM UTC+2, Anton Ertl wrote:AFAIK it was more usual to have screens match the video properties of the
I can't speak for the C64, but the crudely converted FIG editor was close toWere the 40 char lines horribly constraining?Not particularly. It was the display width of the C64. Of course, I
found the 80-wide screens (and later windows) on more capable machines >>>> preferable, but there is alwas some limit.
unusable on the ZX Spectrum - since that one had 32*22 lines. Which meant >>> the thing was scrolling off screen all the time.
It was NOT the fault of the editor itself, though. Once used on a standard 80*25
screen it was perfectly usable. I was busy interfacing a 64 chars driver with
my ZX Spectrum Forth, but then the IBM PC came and I never finished it.
machine. The VIC-20 presented challenges due to the limited display. One
forth got around it with a scrolling 64x16 full-screen editor.
Much like using Google groups on a phone in desktops, as the mobile version won't let you start a thread or reply for years now, and likely do it much better,
as even now what I'm typing is off screen, and sometimes it just flash repositions
on and off screen every key stroke (not to mention not truncating lines to the
regular length). Those days weren't as bad as they seem. Just now bad programmers and designers have more opportunity to stuff it up. Like a dog chasing it's tail trying to fix everything.
On 6/09/2022 1:26 pm, Wayne morellini wrote:
On Tuesday, September 6, 2022 at 11:06:50 AM UTC+10, dxforth wrote:
On 5/09/2022 7:34 pm, Hans Bezemer wrote:
On Monday, September 5, 2022 at 10:38:41 AM UTC+2, Anton Ertl wrote: >>>>> Were the 40 char lines horribly constraining?
Not particularly. It was the display width of the C64. Of course, II can't speak for the C64, but the crudely converted FIG editor was close to
found the 80-wide screens (and later windows) on more capable machines >>>> preferable, but there is alwas some limit.
unusable on the ZX Spectrum - since that one had 32*22 lines. Which meant >>> the thing was scrolling off screen all the time.
It was NOT the fault of the editor itself, though. Once used on a standard 80*25
screen it was perfectly usable. I was busy interfacing a 64 chars driver with
my ZX Spectrum Forth, but then the IBM PC came and I never finished it. >> AFAIK it was more usual to have screens match the video properties of the >> machine. The VIC-20 presented challenges due to the limited display. One >> forth got around it with a scrolling 64x16 full-screen editor.
Much like using Google groups on a phone in desktops, as the mobile version won't let you start a thread or reply for years now, and likely do it much better,Did that several years ago while waiting to be connected to the NBN.
as even now what I'm typing is off screen, and sometimes it just flash repositions
on and off screen every key stroke (not to mention not truncating lines to the
regular length). Those days weren't as bad as they seem. Just now bad programmers and designers have more opportunity to stuff it up. Like a dog chasing it's tail trying to fix everything.
From your description it appears nothing has changed...
Still use classic blocks and get by with simple fig line editor.
One time in the past make the simplest and dirtiest line editor
for fun, something a notch above CAT . Ended up using it on a regular
basis so I had to upgrade it some to be tolerable. The fig editor is
way much nicer; have no complaints.
WRT filling up a source screen, the editor has Zi (vim command prefix "Z", "i" == "insert") which splits the source screen at the cursor, pushing
the lower half into a new, following block (growing the size of the source file by 1 block).
On 6/09/2022 1:26 pm, Wayne morellini wrote:
On Tuesday, September 6, 2022 at 11:06:50 AM UTC+10, dxforth wrote:
On 5/09/2022 7:34 pm, Hans Bezemer wrote:
On Monday, September 5, 2022 at 10:38:41 AM UTC+2, Anton Ertl wrote: >>>>> Were the 40 char lines horribly constraining?
Not particularly. It was the display width of the C64. Of course, II can't speak for the C64, but the crudely converted FIG editor was close to
found the 80-wide screens (and later windows) on more capable machines >>>> preferable, but there is alwas some limit.
unusable on the ZX Spectrum - since that one had 32*22 lines. Which meant >>> the thing was scrolling off screen all the time.
It was NOT the fault of the editor itself, though. Once used on a standard 80*25
screen it was perfectly usable. I was busy interfacing a 64 chars driver with
my ZX Spectrum Forth, but then the IBM PC came and I never finished it. >> AFAIK it was more usual to have screens match the video properties of the >> machine. The VIC-20 presented challenges due to the limited display. One >> forth got around it with a scrolling 64x16 full-screen editor.
Much like using Google groups on a phone in desktops, as the mobile version won't let you start a thread or reply for years now, and likely do it much better,Did that several years ago while waiting to be connected to the NBN.
as even now what I'm typing is off screen, and sometimes it just flash repositions
on and off screen every key stroke (not to mention not truncating lines to the
regular length). Those days weren't as bad as they seem. Just now bad programmers and designers have more opportunity to stuff it up. Like a dog chasing it's tail trying to fix everything.
From your description it appears nothing has changed...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 18:39:41 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,092 |