Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #58701 > unrolled thread

gforth and shared libraries

Back to article view | Back to comp.lang.forth

Contents

  gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-05 17:01 +0200
    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-05 17:44 +0200
      Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:24 +0000
        Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 10:48 +0200
          Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:03 +0000
            Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:40 +0200
            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 22:27 +0200
              Re: gforth and shared libraries Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:57 +0000
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 10:44 +0200
                  Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 11:26 +0000
                    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 17:08 +0200
              Re: gforth and shared libraries pahihu <pahihu@gmail.com> - 2017-05-09 10:31 -0700
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 09:40 +0200
          Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:37 +0200
            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 22:50 +0200
              Re: gforth and shared libraries minforth@arcor.de - 2017-05-07 14:41 -0700
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 10:49 +0200
                  Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 02:16 -0700
                    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 16:32 +0200
                      Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 08:00 -0700
                        Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 17:52 +0200
                          Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 09:33 -0700
                          Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 15:44 +0000
                            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 09:51 +0200
                              Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 10:16 +0000
                                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 12:31 +0200
                                Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 12:51 +0200

Page 1 of 2  [1] 2  Next page →

#58701 — gforth and shared libraries

Hello,

for my work I would have access to shared libraries.
unfortunately the source code of gforth is not trivial and
hence I have found and tryied so far:

s" db/script.so" open-lib constant so  \ load my small dynamic link lib
s" script" so lib-sym wcall \ call the function script

I set a breakpoint at script() but ..

Breakpoint 1, script (args=0x2aaaac0ff000 "") at script.c:10
10		printf("<h1>Hello From Script</h1>");
(gdb) bt
#0  script (args=0x2aaaac0ff000 "") at script.c:10
#1  0x0000000000408edc in gforth_engine (ip0=0x2aaaac0ff000, 
ip0@entry=0x2aaaab903620, sp0=0x2aaaac0feff8, rp0=0x408ebc,
    rp0@entry=0x2aaaac108c00, fp0=0x2aaaac104000, lp0=0x6c <Address 
0x6c out of bounds>, lp0@entry=0x2aaaac10da00 "") at prim:2480
#2  0x0000000000411a3b in gforth_go (image=image@entry=0x2aaaab8f9038, 
stack=<optimized out>, stack@entry=4,
    entries=entries@entry=0x7fffffffe4b0) at ./main.c:754
#3  0x0000000000404513 in main (argc=<optimized out>, argv=<optimized 
out>, env=<optimized out>) at ./main.c:2349

I only can guess what the meaning of the parameters ip0, ip0@entry ... are

I even haven't found anything in the documentation about open-lib, 
lib-sym and wcall
(there are more system related words to explore)

so, how is the interface for wcall defined ?

I would be grateful for any help

best wishes
Andreas Klimas

[toc] | [next] | [standalone]

#58706

sorry, I have found the solution in the gforth documentation now

"5.25.8 Low-Level C Interface Words

open-lib       c-addr1 u1 ? u2        gforth       ?open-lib?

lib-sym       c-addr1 u1 u2 ? u3        gforth       ?lib-sym?

lib-error       ? c-addr u        gforth       ?lib-error?
Error message for last failed open-lib or lib-sym.

call-c       ... w ? ...        gforth       ?call-c?
Call the C function pointed to by w. The C function has to access the 
stack itself. The stack pointers are exported in the global variables 
gforth_SP and gforth_FP."

my mistake was in using wcall instead of call-c (I think).
Now all is working fine.

> Hello,
> 
> for my work I would have access to shared libraries.
> unfortunately the source code of gforth is not trivial and
> hence I have found and tryied so far:
> 
> s" db/script.so" open-lib constant so  \ load my small dynamic link lib
> s" script" so lib-sym wcall \ call the function script
> 
> I set a breakpoint at script() but ..
> 
> Breakpoint 1, script (args=0x2aaaac0ff000 "") at script.c:10
> 10		printf("<h1>Hello From Script</h1>");
> (gdb) bt
> #0  script (args=0x2aaaac0ff000 "") at script.c:10
> #1  0x0000000000408edc in gforth_engine (ip0=0x2aaaac0ff000, 
> ip0@entry=0x2aaaab903620, sp0=0x2aaaac0feff8, rp0=0x408ebc,
>     rp0@entry=0x2aaaac108c00, fp0=0x2aaaac104000, lp0=0x6c <Address 
> 0x6c out of bounds>, lp0@entry=0x2aaaac10da00 "") at prim:2480
> #2  0x0000000000411a3b in gforth_go (image=image@entry=0x2aaaab8f9038, 
> stack=<optimized out>, stack@entry=4,
>     entries=entries@entry=0x7fffffffe4b0) at ./main.c:754
> #3  0x0000000000404513 in main (argc=<optimized out>, argv=<optimized 
> out>, env=<optimized out>) at ./main.c:2349
> 
> I only can guess what the meaning of the parameters ip0, ip0@entry ... are
> 
> I even haven't found anything in the documentation about open-lib, 
> lib-sym and wcall
> (there are more system related words to explore)
> 
> so, how is the interface for wcall defined ?
> 
> I would be grateful for any help
> 
> best wishes
> Andreas Klimas

[toc] | [prev] | [next] | [standalone]

#58738

Andreas Klimas <klimas@w3group.de> writes:
>sorry, I have found the solution in the gforth documentation now
>
>"5.25.8 Low-Level C Interface Words

Is there any particular reason why you do not want to use the
higher-level C interface?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#58757

On 2017-05-06 16:24:11 +0000, Anton Ertl said:

> Andreas Klimas <klimas@w3group.de> writes:
>> sorry, I have found the solution in the gforth documentation now
>> 
>> "5.25.8 Low-Level C Interface Words
> 
> Is there any particular reason why you do not want to use the
> higher-level C interface?
> 
> - anton

no, not really.
I'm already using a shared library in my C project (to dynamically
reload changed code while the application is still running).

So I thought I give them a shot.

What I really want to do is to mmap a shared file for persistent storage,
like block but without the need of the word update. Maybe
is it possible to make a direct systemcall (int 80) ?.
I'm not planning to use any C code because I want to
cut the requirements for a c-compiler.

I'm still exploring gforth and SwiftForth and beeing excited of both.

best wishes
Andreas Klimas

[toc] | [prev] | [next] | [standalone]

#58762

Andreas Klimas <klimas@w3group.de> writes:
>What I really want to do is to mmap a shared file for persistent storage,
>like block but without the need of the word update. Maybe
>is it possible to make a direct systemcall (int 80) ?.
>I'm not planning to use any C code because I want to
>cut the requirements for a c-compiler.

Sure it's possible.  I would not do it, though.  If you have the
current development version of Gforth, you can use unix/mmap.fs, and
because the generated C code is compiled while Gforth is built, so you
don't need a C compiler at run-time.

As for not needing UPDATE, yes that happens automatically with mmap,
but you still need to msync or munmap to make sure the data is written
back to persistent storage.  And if the system crashes between your
changes and the msync()/munmap(), the persistent state may contain
some changes, but not necessarily all of them, and you don't know
which changes you get and which not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#58766

In article <2017May7.120327@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andreas Klimas <klimas@w3group.de> writes:
>>What I really want to do is to mmap a shared file for persistent storage,
>>like block but without the need of the word update. Maybe
>>is it possible to make a direct systemcall (int 80) ?.
>>I'm not planning to use any C code because I want to
>>cut the requirements for a c-compiler.
>
>Sure it's possible.  I would not do it, though.  If you have the
>current development version of Gforth, you can use unix/mmap.fs, and
>because the generated C code is compiled while Gforth is built, so you
>don't need a C compiler at run-time.

This demonstrates the advantage in using a c-based
Forth on a c-based system.

<SNIP>

>
>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#58788

On 2017-05-07 10:03:27 +0000, Anton Ertl said:

> Andreas Klimas <klimas@w3group.de> writes:
>> What I really want to do is to mmap a shared file for persistent storage,
>> like block but without the need of the word update. Maybe
>> is it possible to make a direct systemcall (int 80) ?.
>> I'm not planning to use any C code because I want to
>> cut the requirements for a c-compiler.
> 
> Sure it's possible.  I would not do it, though.  If you have the
> current development version of Gforth, you can use unix/mmap.fs, and
> because the generated C code is compiled while Gforth is built, so you
> don't need a C compiler at run-time.

unfortunately the current development version didn't compile on my Mac
and I don't want to investigate work in this direction.
Using readily working development systems (like SwiftForth, Smalltalk
or Racket Scheme, only to name a few) is a big benefit for me.

the reason for using gforth is to get the binary without the need of
an installed C compiler. I'm working on different computers and
operation systems (Mac, Linux, Windows) and I don't want,
or even can't, install a C development toolchain. But I can scp or
ftp a simple exe-file.  So call me a bit lazy.

> 
> As for not needing UPDATE, yes that happens automatically with mmap,
> but you still need to msync or munmap to make sure the data is written
> back to persistent storage.  And if the system crashes between your
> changes and the msync()/munmap(), the persistent state may contain
> some changes, but not necessarily all of them, and you don't know
> which changes you get and which not.

a long time ago we talked about the same topic (in using mmap) and you
told me the same argument. well, now, 10 years later, I'm using this method
with a great success and have never lost any data. It is just simple and
fast. very different to our SQL-Server experience (in speed and
reliability).
a systemcrash nowadays is very seldom. Our internet server has
a few years uptime.

thank you for your response
Andreas Klimas

> 
> - anton

[toc] | [prev] | [next] | [standalone]

#58799

Am Sun, 07 May 2017 22:27:21 +0200 schrieb Andreas Klimas:

> unfortunately the current development version didn't compile on my Mac
> and I don't want to investigate work in this direction.

Compilation on Mac OS X is automatically tested on every checkin with 
Travis.

But I haven't yet got around to create a brew tap for it so that you 
could just install it from precompiled binaries.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#58809

On 2017-05-07 23:57:20 +0000, Bernd Paysan said:

> But I haven't yet got around to create a brew tap for it so that you
> could just install it from precompiled binaries.

I'm using
$ git clone https://github.com/forthy42/gforth.git

there is no configure, right ?

[toc] | [prev] | [next] | [standalone]

#58822

Andreas Klimas <klimas@w3group.de> writes:
>On 2017-05-07 23:57:20 +0000, Bernd Paysan said:
>
>> But I haven't yet got around to create a brew tap for it so that you
>> could just install it from precompiled binaries.
>
>I'm using
>$ git clone https://github.com/forthy42/gforth.git
>
>there is no configure, right ?

If you build from git, you need more software installed, including
gforth and autoconf (which generates the "configure" script).  If you
build from the tarball, a number of generated files (including
"configure") come with the tarball, and you need fewer tools.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#58841

On 2017-05-08 11:26:57 +0000, Anton Ertl said:

> Andreas Klimas <klimas@w3group.de> writes:
>> On 2017-05-07 23:57:20 +0000, Bernd Paysan said:
>> 
>>> But I haven't yet got around to create a brew tap for it so that you
>>> could just install it from precompiled binaries.
>> 
>> I'm using
>> $ git clone https://github.com/forthy42/gforth.git
>> 
>> there is no configure, right ?
> 
> If you build from git, you need more software installed, including
> gforth and autoconf (which generates the "configure" script).  If you
> build from the tarball, a number of generated files (including
> "configure") come with the tarball, and you need fewer tools.
> 
> - anton

the official tar ball on the gnu site is gforth-0.7.3.tar.gz which I'm 
already using.

the other tar mentioned in this group by Jos (thank you) points to:
http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
which compiles fine now on MacOS and Linux.

[toc] | [prev] | [next] | [standalone]

#58907

2017. május 7., vasárnap 22:27:23 UTC+2 időpontban Andreas Klimas a következőt írta:
> an installed C compiler. I'm working on different computers and
> operation systems (Mac, Linux, Windows) and I don't want,
> or even can't, install a C development toolchain. But I can scp or
> ftp a simple exe-file.  So call me a bit lazy.

I use SwiftForth (32bit) and iForth (64bit) on Mac and Windows.
Marcel Hendrix provides excellent support for iForth if you have
any problems.

pahihu

[toc] | [prev] | [next] | [standalone]

#58936

On 2017-05-09 17:31:50 +0000, pahihu said:

> 2017. május 7., vasárnap 22:27:23 UTC+2 időpontban Andreas Klimas a 
> következőt írta:
>> an installed C compiler. I'm working on different computers and
>> operation systems (Mac, Linux, Windows) and I don't want,
>> or even can't, install a C development toolchain. But I can scp or
>> ftp a simple exe-file.  So call me a bit lazy.
> 
> I use SwiftForth (32bit) and iForth (64bit) on Mac and Windows.
> Marcel Hendrix provides excellent support for iForth if you have
> any problems.
> 
> pahihu

Yes, I'm working with SwiftForth on Mac and on Linux and it's really
nice. The way to make turnkey applications is famous.
Handrix doesn't have an evaluation version and I don't have a
PayPal account, so this option is delayed.

Andreas Klimas

[toc] | [prev] | [next] | [standalone]

#58765

In article <oemmqp$jr$1@dont-email.me>,
Andreas Klimas  <klimas@w3group.de> wrote:
>On 2017-05-06 16:24:11 +0000, Anton Ertl said:
>
>> Andreas Klimas <klimas@w3group.de> writes:
>>> sorry, I have found the solution in the gforth documentation now
>>>
>>> "5.25.8 Low-Level C Interface Words
>>
>> Is there any particular reason why you do not want to use the
>> higher-level C interface?
>>
>> - anton
>
>no, not really.
>I'm already using a shared library in my C project (to dynamically
>reload changed code while the application is still running).
>
>So I thought I give them a shot.
>
>What I really want to do is to mmap a shared file for persistent storage,
>like block but without the need of the word update. Maybe
>is it possible to make a direct systemcall (int 80) ?.
>I'm not planning to use any C code because I want to
>cut the requirements for a c-compiler.

Good luck. The new wave is to replace well documented system calls
by a "compatible" .so call that can be changed at whim, mimicking
the ddl-hell of you-know-what. I gave up on  making a warm start
for lina64 on ^C because of the problems to get the
signal system call under control.

That is not necessarily true for mmap.
I would have investigated mmap if not the man page on my
debian system lies about the where abouts of mmap.h .

>
>I'm still exploring gforth and SwiftForth and beeing excited of both.
>
>best wishes
>Andreas Klimas
>

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#58789

>> 
>> What I really want to do is to mmap a shared file for persistent storage,
>> like block but without the need of the word update. Maybe
>> is it possible to make a direct systemcall (int 80) ?.
>> I'm not planning to use any C code because I want to
>> cut the requirements for a c-compiler.
> 
> Good luck. The new wave is to replace well documented system calls
> by a "compatible" .so call that can be changed at whim, mimicking
> the ddl-hell of you-know-what. I gave up on  making a warm start
> for lina64 on ^C because of the problems to get the
> signal system call under control.

I have seen your great site and your large effort in building forth.
I want to work with forth (not C). I don't want to build my own Forth.
it should be ANSI compliant because I don't want to have a vendor lock.

unfortunately for my work I need 64 bit. Because my mmap persistent
storage uses some Gigs in size which didn't fit into 32 bits.
anyway, if I can't get mmap, i have to give up.
to work with 32 bit, maybe I can work around with segmentation
and mmap 128 or 256 MB blocks. but ... I don't know how long
we support 32 bit on our server. and this should be a solution
for years.
Another thing are (native) threads. I know at least SwiftForth
does have native threads, but SwiftForth supports only 32 bits.

Or am I doing wrong if I want to access all the 64 Gigs of RAM
of our server with forth ?

thank you
best wishes
Andreas Klimas


> 
> That is not necessarily true for mmap.
> I would have investigated mmap if not the man page on my
> debian system lies about the where abouts of mmap.h .
> 
>> 
>> I'm still exploring gforth and SwiftForth and beeing excited of both.
>> 
>> best wishes
>> Andreas Klimas
>> 
> 
> Groetjes Albert

[toc] | [prev] | [next] | [standalone]

#58792

Am Sonntag, 7. Mai 2017 22:50:45 UTC+2 schrieb Andreas Klimas:
> >> 
> >> What I really want to do is to mmap a shared file for persistent storage,
> >> like block but without the need of the word update. Maybe
> >> is it possible to make a direct systemcall (int 80) ?.
> >> I'm not planning to use any C code because I want to
> >> cut the requirements for a c-compiler.
> > 
> > Good luck. The new wave is to replace well documented system calls
> > by a "compatible" .so call that can be changed at whim, mimicking
> > the ddl-hell of you-know-what. I gave up on  making a warm start
> > for lina64 on ^C because of the problems to get the
> > signal system call under control.
> 
> I have seen your great site and your large effort in building forth.
> I want to work with forth (not C). I don't want to build my own Forth.
> it should be ANSI compliant because I don't want to have a vendor lock.
> 
> unfortunately for my work I need 64 bit. Because my mmap persistent
> storage uses some Gigs in size which didn't fit into 32 bits.
> anyway, if I can't get mmap, i have to give up.
> to work with 32 bit, maybe I can work around with segmentation
> and mmap 128 or 256 MB blocks. but ... I don't know how long
> we support 32 bit on our server. and this should be a solution
> for years.
> Another thing are (native) threads. I know at least SwiftForth
> does have native threads, but SwiftForth supports only 32 bits.
> 
> Or am I doing wrong if I want to access all the 64 Gigs of RAM
> of our server with forth ?
> 

I would say that might be true when you have to handle data objects persistently in memory of about > 3 gigs size. If not, 32 bits are sufficient for most applications. OTOH large image or video processing might benefit from 64 bit for good performance.

And most OS remap physical to virtual address ranges anyhow, so it is rather unusual to address the full physical address space. 

[toc] | [prev] | [next] | [standalone]

#58810

>> 
>> Or am I doing wrong if I want to access all the 64 Gigs of RAM
>> of our server with forth ?
>> 
> 
> I would say that might be true when you have to handle data objects 
> persistently in memory of about > 3 gigs size. If not, 32 bits are 
> sufficient for most applications. OTOH large image or video processing 
> might benefit from 64 bit for good performance.
> 
> And most OS remap physical to virtual address ranges anyhow, so it is 
> rather unusual to address the full physical address space.

the database is large, some billions records. but not all data is
used all the time, so partitioning could be possible. Is the effort
worth it ?

[toc] | [prev] | [next] | [standalone]

#58817

Am Montag, 8. Mai 2017 10:49:27 UTC+2 schrieb Andreas Klimas:
> >> 
> >> Or am I doing wrong if I want to access all the 64 Gigs of RAM
> >> of our server with forth ?
> >> 
> > 
> > I would say that might be true when you have to handle data objects 
> > persistently in memory of about > 3 gigs size. If not, 32 bits are 
> > sufficient for most applications. OTOH large image or video processing 
> > might benefit from 64 bit for good performance.
> > 
> > And most OS remap physical to virtual address ranges anyhow, so it is 
> > rather unusual to address the full physical address space.
> 
> the database is large, some billions records. but not all data is
> used all the time, so partitioning could be possible. Is the effort
> worth it ?

are you the sole user and admin on the server? no concurrent db access i.e. the db is "dormant"?

[toc] | [prev] | [next] | [standalone]

#58836

On 2017-05-08 09:16:03 +0000, minforth@arcor.de said:

> Am Montag, 8. Mai 2017 10:49:27 UTC+2 schrieb Andreas Klimas:
>>>> 
>>>> Or am I doing wrong if I want to access all the 64 Gigs of RAM
>>>> of our server with forth ?
>>>> 
>>> 
>>> I would say that might be true when you have to handle data objects
>>> persistently in memory of about > 3 gigs size. If not, 32 bits are
>>> sufficient for most applications. OTOH large image or video processing
>>> might benefit from 64 bit for good performance.
>>> 
>>> And most OS remap physical to virtual address ranges anyhow, so it is
>>> rather unusual to address the full physical address space.
>> 
>> the database is large, some billions records. but not all data is
>> used all the time, so partitioning could be possible. Is the effort
>> worth it ?
> 
> are you the sole user and admin on the server? no concurrent db access 
> i.e. the db is "dormant"?

no, for sure not. I don't want to go to deep into detail here.
there are some databases and many users. And I'm not the
sysadmin. Data wil be synchronized in background to/from
Oracle server elswhere. The Software (written entirely in C)
is really fast, about 1000x faster than direct SQL Connect.
Now I want to show how far I can get with forth. Because
Forth is highly interactive productivity should be much better
then. I want to rewrite our GDV Parser (which is a simple
portable ASCII data format used by german insurance
companies for data exchange.
http://www.gdv-online.de/vuvm/ (german))

[toc] | [prev] | [next] | [standalone]

#58839

Am Montag, 8. Mai 2017 16:32:08 UTC+2 schrieb Andreas Klimas:
> On 2017-05-08 09:16:03 +0000, minforth@arcor.de said:
> 
> > Am Montag, 8. Mai 2017 10:49:27 UTC+2 schrieb Andreas Klimas:
> >>>> 
> >>>> Or am I doing wrong if I want to access all the 64 Gigs of RAM
> >>>> of our server with forth ?
> >>>> 
> >>> 
> >>> I would say that might be true when you have to handle data objects
> >>> persistently in memory of about > 3 gigs size. If not, 32 bits are
> >>> sufficient for most applications. OTOH large image or video processing
> >>> might benefit from 64 bit for good performance.
> >>> 
> >>> And most OS remap physical to virtual address ranges anyhow, so it is
> >>> rather unusual to address the full physical address space.
> >> 
> >> the database is large, some billions records. but not all data is
> >> used all the time, so partitioning could be possible. Is the effort
> >> worth it ?
> > 
> > are you the sole user and admin on the server? no concurrent db access 
> > i.e. the db is "dormant"?
> 
> no, for sure not. I don't want to go to deep into detail here.
> there are some databases and many users. And I'm not the
> sysadmin. Data wil be synchronized in background to/from
> Oracle server elswhere. The Software (written entirely in C)
> is really fast, about 1000x faster than direct SQL Connect.
> Now I want to show how far I can get with forth. Because
> Forth is highly interactive productivity should be much better
> then. I want to rewrite our GDV Parser (which is a simple
> portable ASCII data format used by german insurance
> companies for data exchange.
> http://www.gdv-online.de/vuvm/ (german))

Okay, thanks for the insights. I'd be surprised if the parser needs
direct access to the 64 gig physical memory address range, but it's just
my wild guess into the blue.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web