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

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

wina64 : a 64 bit native MS-Windows Forth in beta

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

Contents

  wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-08 09:14 +0200
    Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-08 09:29 +0200
    Re: wina64 : a 64 bit native MS-Windows Forth in beta "HAA" <someone@microsoft.com> - 2017-04-08 21:04 +1000
    Re: wina64 : a 64 bit native MS-Windows Forth in beta rickman <gnuarm@gmail.com> - 2017-04-08 13:26 -0400
      Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-08 23:44 +0200
        Re: wina64 : a 64 bit native MS-Windows Forth in beta rickman <gnuarm@gmail.com> - 2017-04-09 01:13 -0400
          Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-09 12:43 +0200
            Re: wina64 : a 64 bit native MS-Windows Forth in beta minforth@arcor.de - 2017-04-09 04:31 -0700
              Re: wina64 : a 64 bit native MS-Windows Forth in beta john <anon@example.com> - 2017-04-09 13:13 +0100
              Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-09 14:43 +0200
                Re: wina64 : a 64 bit native MS-Windows Forth in beta minforth@arcor.de - 2017-04-09 08:56 -0700
                  Re: wina64 : a 64 bit native MS-Windows Forth in beta foxaudioresearch@gmail.com - 2017-04-09 09:44 -0700
                    Re: wina64 : a 64 bit native MS-Windows Forth in beta minforth@arcor.de - 2017-04-09 22:07 -0700
                      Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-10 12:40 +0200
            Re: wina64 : a 64 bit native MS-Windows Forth in beta rickman <gnuarm@gmail.com> - 2017-04-10 02:15 -0400
              Re: wina64 : a 64 bit native MS-Windows Forth in beta Julian Fondren <julian.fondren@gmail.com> - 2017-04-09 23:21 -0700
                Re: wina64 : a 64 bit native MS-Windows Forth in beta Paul Rubin <no.email@nospam.invalid> - 2017-04-10 01:40 -0700
                  Re: wina64 : a 64 bit native MS-Windows Forth in beta Julian Fondren <julian.fondren@gmail.com> - 2017-04-10 04:15 -0700
                    Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-10 13:49 +0200
                Re: wina64 : a 64 bit native MS-Windows Forth in beta rickman <gnuarm@gmail.com> - 2017-04-10 10:05 -0400
                  Re: wina64 : a 64 bit native MS-Windows Forth in beta anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-10 14:27 +0000
                  Re: wina64 : a 64 bit native MS-Windows Forth in beta albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-10 20:05 +0200
                    Re: wina64 : a 64 bit native MS-Windows Forth in beta minforth@arcor.de - 2017-04-10 14:26 -0700

Page 1 of 2  [1] 2  Next page →

#56852 — wina64 : a 64 bit native MS-Windows Forth in beta

A beta version can be found via
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS

If nobody reports embarrassing problems it shortly will be pushed to
    https://github.com/albertvanderhorst/ciforth
and after more testing a 6.0.0 release will be available in
    https://github.com/albertvanderhorst/ciforth/release

The usual ciforth features:
GPL/LGPL, runtime: one executable and one library, complete specific
documentation, compiles to native exe files, one assembler source
file.

NOTE: KEY and KEY? may not be fully functional. SYSTEM works
SAVE-SYSTEM has not been adequately tested because of virus checkers
that immediately delete the generated .EXE files.

Groetjes Albert

1] Despite the name kernel32.dll is 64 bits software.
-- 
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] | [next] | [standalone]

#56854

In article <oca2jp$96m$1@cherry.spenarnc.xs4all.nl>,
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>A beta version can be found via
>http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS

Somehow I deleted the introduction:

The 32 bit version of ciforth wina32.exe has now a baby sister
wina64.exe, which is a 64 bit Forth that should run on all 64 bit
MS-Windows system without further requirements.
It uses kernel32.dll 1] for all the system calls (file i/o , SYSTEM ,
MS , commandline arguments etc.) and nothing else.
-- 
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]

#56859

Albert van der Horst wrote:
> ...
> SAVE-SYSTEM has not been adequately tested because of virus checkers
> that immediately delete the generated .EXE files.

All the world knows Forth is a virus that must be eliminated :)

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

#56873

On 4/8/2017 3:14 AM, Albert van der Horst wrote:
> A beta version can be found via
> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
>
> If nobody reports embarrassing problems it shortly will be pushed to
>     https://github.com/albertvanderhorst/ciforth
> and after more testing a 6.0.0 release will be available in
>     https://github.com/albertvanderhorst/ciforth/release
>
> The usual ciforth features:
> GPL/LGPL, runtime: one executable and one library, complete specific
> documentation, compiles to native exe files, one assembler source
> file.
>
> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
> SAVE-SYSTEM has not been adequately tested because of virus checkers
> that immediately delete the generated .EXE files.
>
> Groetjes Albert
>
> 1] Despite the name kernel32.dll is 64 bits software.

Perhaps I don't understand what "native" means.  I thought that would be 
a Forth that doesn't use an operating system.  Obviously that isn't 
true.  What does "native" mean?

-- 

Rick C

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

#56879

In article <ocb69s$mg2$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/8/2017 3:14 AM, Albert van der Horst wrote:
>> A beta version can be found via
>> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
>>
>> If nobody reports embarrassing problems it shortly will be pushed to
>>     https://github.com/albertvanderhorst/ciforth
>> and after more testing a 6.0.0 release will be available in
>>     https://github.com/albertvanderhorst/ciforth/release
>>
>> The usual ciforth features:
>> GPL/LGPL, runtime: one executable and one library, complete specific
>> documentation, compiles to native exe files, one assembler source
>> file.
>>
>> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
>> SAVE-SYSTEM has not been adequately tested because of virus checkers
>> that immediately delete the generated .EXE files.
>>
>> Groetjes Albert
>>
>> 1] Despite the name kernel32.dll is 64 bits software.
>
>Perhaps I don't understand what "native" means.  I thought that would be
>a Forth that doesn't use an operating system.  Obviously that isn't
>true.  What does "native" mean?

Read the description and associate that with native in a ciforth context.

In 2000 I had 2 configurations for a Linux Forth, one with c-calls
for KEY and EMIT and READ-BLOCK and one native, i.e. direct Linux
system calls. That stuck. Then there were similar MS-DOS and MS-Windows
Forth's.

>Rick C

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]

#56895

On 4/8/2017 5:44 PM, Albert van der Horst wrote:
> In article <ocb69s$mg2$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/8/2017 3:14 AM, Albert van der Horst wrote:
>>> A beta version can be found via
>>> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
>>>
>>> If nobody reports embarrassing problems it shortly will be pushed to
>>>     https://github.com/albertvanderhorst/ciforth
>>> and after more testing a 6.0.0 release will be available in
>>>     https://github.com/albertvanderhorst/ciforth/release
>>>
>>> The usual ciforth features:
>>> GPL/LGPL, runtime: one executable and one library, complete specific
>>> documentation, compiles to native exe files, one assembler source
>>> file.
>>>
>>> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
>>> SAVE-SYSTEM has not been adequately tested because of virus checkers
>>> that immediately delete the generated .EXE files.
>>>
>>> Groetjes Albert
>>>
>>> 1] Despite the name kernel32.dll is 64 bits software.
>>
>> Perhaps I don't understand what "native" means.  I thought that would be
>> a Forth that doesn't use an operating system.  Obviously that isn't
>> true.  What does "native" mean?
>
> Read the description and associate that with native in a ciforth context.
>
> In 2000 I had 2 configurations for a Linux Forth, one with c-calls
> for KEY and EMIT and READ-BLOCK and one native, i.e. direct Linux
> system calls. That stuck. Then there were similar MS-DOS and MS-Windows
> Forth's.

I'm sorry, I don't follow what you are saying.  What is a c-call for 
KEY/EMIT?  I'm lost here.

-- 

Rick C

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

#56919

In article <occfne$61v$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/8/2017 5:44 PM, Albert van der Horst wrote:
>> In article <ocb69s$mg2$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>>> On 4/8/2017 3:14 AM, Albert van der Horst wrote:
>>>> A beta version can be found via
>>>> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
>>>>
>>>> If nobody reports embarrassing problems it shortly will be pushed to
>>>>     https://github.com/albertvanderhorst/ciforth
>>>> and after more testing a 6.0.0 release will be available in
>>>>     https://github.com/albertvanderhorst/ciforth/release
>>>>
>>>> The usual ciforth features:
>>>> GPL/LGPL, runtime: one executable and one library, complete specific
>>>> documentation, compiles to native exe files, one assembler source
>>>> file.
>>>>
>>>> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
>>>> SAVE-SYSTEM has not been adequately tested because of virus checkers
>>>> that immediately delete the generated .EXE files.
>>>>
>>>> Groetjes Albert
>>>>
>>>> 1] Despite the name kernel32.dll is 64 bits software.
>>>
>>> Perhaps I don't understand what "native" means.  I thought that would be
>>> a Forth that doesn't use an operating system.  Obviously that isn't
>>> true.  What does "native" mean?
>>
>> Read the description and associate that with native in a ciforth context.
>>
>> In 2000 I had 2 configurations for a Linux Forth, one with c-calls
>> for KEY and EMIT and READ-BLOCK and one native, i.e. direct Linux
>> system calls. That stuck. Then there were similar MS-DOS and MS-Windows
>> Forth's.
>
>I'm sorry, I don't follow what you are saying.  What is a c-call for
>KEY/EMIT?  I'm lost here.

It means:

The assembler file contains
-----------------
;  ***********
;  *   KEY   *
;  ***********
;
N_KEY:
        DC      3
        DB      "KEY"
KEY:
        DC    KEY+HEADSIZE
        DC    KEY+HEADSIZE
        DC    0x0
        DC    ACCEP
        DC    N_KEY

        CALL    c_key    ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        PUSH    EAX
        JMP NEXT
;
----------------

A c-file contains
-------------

/* KEY */
int c_key( void )     /* <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< */
{
  char key;
  int i;
  tty_keymode(&std_in);
  i=read(0, &key, 1);
  return key;
}

-----------

Then the c-file is compiled using a c-compiler and the
object is linked to the main assembler file.

What else could it mean for Pete's sake?

All xxna versions, say normal versions, of ciforth contain a place
where it says in the one assembler source file:
-------------------------

;  ***********
;  *   KEY   *
;  ***********
;
        ALIGN    8
N_KEY:
        DQ      3
        DB      "KEY"
        ALIGN    8
KEY:
        DQ    DOCOL
        DQ    KEY+HEADSIZE
        DQ    0x0
        DQ    PACCEP
        DQ    N_KEY
        DQ    0
        DQ    0

        DQ      ONE, LIT, RAWIO, STTERM ; Do not wait for CR
        DQ      ZERO, SPFET     ; Expect single key on stack
        DQ      ZERO            ; Standard input
        DQ      SWAP, ONE       ; Buffer and length
        DQ      LIT, read, XOS
        DQ      LDUP, QERRUR
        DQ      ZEQU, LIT, -EPIPE, LAND, QERRUR ; Presumably end of pipe.
        DQ      ONE, LIT, RAWIO, STTERM       ; Toggle back
        DQ      SEMIS
;

---------------------
(This is in fact Forth source code, inspectable by SEE).
>
>--
>
>Rick C

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]

#56920

Am Sonntag, 9. April 2017 12:42:22 UTC+2 schrieb Albert van der Horst:
> In article <occfne$61v$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
> >On 4/8/2017 5:44 PM, Albert van der Horst wrote:
> >> In article <ocb69s$mg2$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
> >>> On 4/8/2017 3:14 AM, Albert van der Horst wrote:
> >>>> A beta version can be found via
> >>>> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
> >>>>
> >>>> If nobody reports embarrassing problems it shortly will be pushed to
> >>>>     https://github.com/albertvanderhorst/ciforth
> >>>> and after more testing a 6.0.0 release will be available in
> >>>>     https://github.com/albertvanderhorst/ciforth/release
> >>>>
> >>>> The usual ciforth features:
> >>>> GPL/LGPL, runtime: one executable and one library, complete specific
> >>>> documentation, compiles to native exe files, one assembler source
> >>>> file.
> >>>>
> >>>> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
> >>>> SAVE-SYSTEM has not been adequately tested because of virus checkers
> >>>> that immediately delete the generated .EXE files.
> >>>>
> >>>> Groetjes Albert
> >>>>
> >>>> 1] Despite the name kernel32.dll is 64 bits software.
> >>>
> >>> Perhaps I don't understand what "native" means.  I thought that would be
> >>> a Forth that doesn't use an operating system.  Obviously that isn't
> >>> true.  What does "native" mean?
> >>
> >> Read the description and associate that with native in a ciforth context.
> >>
> >> In 2000 I had 2 configurations for a Linux Forth, one with c-calls
> >> for KEY and EMIT and READ-BLOCK and one native, i.e. direct Linux
> >> system calls. That stuck. Then there were similar MS-DOS and MS-Windows
> >> Forth's.
> >
> >I'm sorry, I don't follow what you are saying.  What is a c-call for
> >KEY/EMIT?  I'm lost here.
> 
> It means:
> 
> The assembler file contains
> -----------------
> ;  ***********
> ;  *   KEY   *
> ;  ***********
> ;
> N_KEY:
>         DC      3
>         DB      "KEY"
> KEY:
>         DC    KEY+HEADSIZE
>         DC    KEY+HEADSIZE
>         DC    0x0
>         DC    ACCEP
>         DC    N_KEY
> 
>         CALL    c_key    ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>         PUSH    EAX
>         JMP NEXT
> ;
> ----------------
> 
> A c-file contains
> -------------
> 
> /* KEY */
> int c_key( void )     /* <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< */
> {
>   char key;
>   int i;
>   tty_keymode(&std_in);
>   i=read(0, &key, 1);
>   return key;
> }
> 
> -----------
> 
> Then the c-file is compiled using a c-compiler and the
> object is linked to the main assembler file.
> 
> What else could it mean for Pete's sake?
> 
> All xxna versions, say normal versions, of ciforth contain a place
> where it says in the one assembler source file:
> -------------------------
> 
> ;  ***********
> ;  *   KEY   *
> ;  ***********
> ;
>         ALIGN    8
> N_KEY:
>         DQ      3
>         DB      "KEY"
>         ALIGN    8
> KEY:
>         DQ    DOCOL
>         DQ    KEY+HEADSIZE
>         DQ    0x0
>         DQ    PACCEP
>         DQ    N_KEY
>         DQ    0
>         DQ    0
> 
>         DQ      ONE, LIT, RAWIO, STTERM ; Do not wait for CR
>         DQ      ZERO, SPFET     ; Expect single key on stack
>         DQ      ZERO            ; Standard input
>         DQ      SWAP, ONE       ; Buffer and length
>         DQ      LIT, read, XOS
>         DQ      LDUP, QERRUR
>         DQ      ZEQU, LIT, -EPIPE, LAND, QERRUR ; Presumably end of pipe.
>         DQ      ONE, LIT, RAWIO, STTERM       ; Toggle back
>         DQ      SEMIS
> ;
> 
> ---------------------
> (This is in fact Forth source code, inspectable by SEE).
> >
> >--
> >
> >Rick C
> 
> 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

DQ for SWAP etc. ??
Alright for a 64-bit Forth VM.
But in my heart I am feeling that it should be more compact. Only absolute addresses are req'd to be 64bit wide. And these are rare.

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

#56923

In article <d2211416-d2ff-49eb-94c0-a01e40f7594e@googlegroups.com>, 
minforth@arcor.de says...
> 
> DQ for SWAP etc. ??
> Alright for a 64-bit Forth VM.
> But in my heart I am feeling that it should be more compact. Only absolute addresses are req'd to be 64bit wide. And these are rare.
> 

This is something I gave some thought to a few weeks ago. 
I've come to the conclusion that a 32 bit system with 64bit extensions built in (in 
fact I'll be looking at variable length) is perhaps a good idea.
Unfortunately I don't have the resources to run the statistics on what that would
do to real world application efficiency - but my gut says it will work fine
on my ultimate hardware even if it slows down intel and other kit just a little.
(Assuming it even does that - as you say - how often is 64 bit needed).

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

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

#56925

In article <d2211416-d2ff-49eb-94c0-a01e40f7594e@googlegroups.com>,
 <minforth@arcor.de> wrote:
>Am Sonntag, 9. April 2017 12:42:22 UTC+2 schrieb Albert van der Horst:
<SNIP>
>> All xxna versions, say normal versions, of ciforth contain a place
>> where it says in the one assembler source file:
>> -------------------------
>>
>> ;  ***********
>> ;  *   KEY   *
>> ;  ***********
>> ;
>>         ALIGN    8
>> N_KEY:
>>         DQ      3
>>         DB      "KEY"
>>         ALIGN    8
>> KEY:
>>         DQ    DOCOL
>>         DQ    KEY+HEADSIZE
>>         DQ    0x0
>>         DQ    PACCEP
>>         DQ    N_KEY
>>         DQ    0
>>         DQ    0
>>
>>         DQ      ONE, LIT, RAWIO, STTERM ; Do not wait for CR
>>         DQ      ZERO, SPFET     ; Expect single key on stack
>>         DQ      ZERO            ; Standard input
>>         DQ      SWAP, ONE       ; Buffer and length
>>         DQ      LIT, read, XOS
>>         DQ      LDUP, QERRUR
>>         DQ      ZEQU, LIT, -EPIPE, LAND, QERRUR ; Presumably end of pipe.
>>         DQ      ONE, LIT, RAWIO, STTERM       ; Toggle back
>>         DQ      SEMIS
>> ;
>>
>> ---------------------
>> (This is in fact Forth source code, inspectable by SEE).
>> >
>> >--
>> >
>> >Rick C
>>
>> Groetjes Albert
>> --
>
>DQ for SWAP etc. ??
>Alright for a 64-bit Forth VM.
>But in my heart I am feeling that it should be more compact. Only absolute addresses are req'd to be 64bit wide. And these are rare.

You're welcome to use the generic ciforth system to make your own version.
Hint:
    Redefine the DC (define cell macro)

      Use sed to replace
          DC   AAP,NOOT MIES
      by
          DC({ AAP,NOOT, MIES })

In the meantime I judge vis-a-vis the design goals of ciforth

1. simple
2. transparent
3. introspective
4 ...

Compact is far down the list. Even 16 bits MSDOS ciforth has
7 cell headers.

Relative addressing looses, because
- it requires a base address, less simple,
- an address cannot be interpreted without the base address,
    less transparent,
-you cannot dump a word from its XT easily, less introspective.

And by the way there is no Virtual Machine in sight.
This is just a binary kernel.
Add a definition of your own and do a SAVE-SYSTEM. There is no
way to tell which definitions were originally in the kernel and
which where added.

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]

#56935

Am Sonntag, 9. April 2017 14:42:18 UTC+2 schrieb Albert van der Horst:
> >DQ for SWAP etc. ??
> >Alright for a 64-bit Forth VM.
> >But in my heart I am feeling that it should be more compact. Only absolute addresses are req'd to be 64bit wide. And these are rare.
> 
> You're welcome to use the generic ciforth system to make your own version.
> Hint:
>     Redefine the DC (define cell macro)
> 
>       Use sed to replace
>           DC   AAP,NOOT MIES
>       by
>           DC({ AAP,NOOT, MIES })
> 
> In the meantime I judge vis-a-vis the design goals of ciforth
> 
> 1. simple
> 2. transparent
> 3. introspective
> 4 ...
> 
> Compact is far down the list. Even 16 bits MSDOS ciforth has
> 7 cell headers.
> 
> Relative addressing looses, because
> - it requires a base address, less simple,
> - an address cannot be interpreted without the base address,
>     less transparent,
> -you cannot dump a word from its XT easily, less introspective.
> 
> And by the way there is no Virtual Machine in sight.
> This is just a binary kernel.
> Add a definition of your own and do a SAVE-SYSTEM. There is no
> way to tell which definitions were originally in the kernel and
> which where added.
> 
> 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

Thanks for the good explanations.

I understand that your hilevel words are address lists, no executable code. They are processed by repeated jmp [eax] in DOCOL. So it's threaded code, not strictly a VM in the common sense.

One must take design decisions, of course. Sometimes they vary. 

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

#56936

Now it is my turn to be confused.

How does a "strict" virtual machine work?

How does threaded implementation make a Forth system not a VM?


BF

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

#56972

Am Sonntag, 9. April 2017 18:44:22 UTC+2 schrieb foxaudio...@gmail.com:
> Now it is my turn to be confused.
> 
> How does a "strict" virtual machine work?
> 
> How does threaded implementation make a Forth system not a VM?
> 
> 
> BF

IMO words and meanings are not always consistent. Although the classic explanation still holds:
http://www.bradrodriguez.com/papers/moving1.htm

Address sequence processing is distributed over the code, not by a forever looping VM software instance which increments an instruction/address/token pointer on the fly.

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

#56991

In article <8fb95d8a-fbc6-48dd-ae9a-3995fc40345b@googlegroups.com>,
 <minforth@arcor.de> wrote:
>Am Sonntag, 9. April 2017 18:44:22 UTC+2 schrieb foxaudio...@gmail.com:
>> Now it is my turn to be confused.
>>
>> How does a "strict" virtual machine work?
>>
>> How does threaded implementation make a Forth system not a VM?
>>
>>
>> BF
>
>IMO words and meanings are not always consistent. Although the classic explanation still holds:
>http://www.bradrodriguez.com/papers/moving1.htm
>
>Address sequence processing is distributed over the code, not by a forever looping VM software instance which increments an instruction/address/token pointer on the fly.

With virtual machines I mean a system like gforth where there is a
startup executable (gforth) and an image (gforth.fi).

ciforth uses "virtual registers" such as Brad Rodriguez defines them.
In fact they only the names are different W/WOR IP/HIP PSP/SPO RSP/RPO .
and they are used in the way Brad describes for ITC.
If you want to call that a virtual machine, be my guest. That term is not
used by Brad. It is a nice reference, by the way.

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]

#56977

On 4/9/2017 6:43 AM, Albert van der Horst wrote:
> In article <occfne$61v$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/8/2017 5:44 PM, Albert van der Horst wrote:
>>> In article <ocb69s$mg2$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>>>> On 4/8/2017 3:14 AM, Albert van der Horst wrote:
>>>>> A beta version can be found via
>>>>> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html#DOWNLOADS
>>>>>
>>>>> If nobody reports embarrassing problems it shortly will be pushed to
>>>>>     https://github.com/albertvanderhorst/ciforth
>>>>> and after more testing a 6.0.0 release will be available in
>>>>>     https://github.com/albertvanderhorst/ciforth/release
>>>>>
>>>>> The usual ciforth features:
>>>>> GPL/LGPL, runtime: one executable and one library, complete specific
>>>>> documentation, compiles to native exe files, one assembler source
>>>>> file.
>>>>>
>>>>> NOTE: KEY and KEY? may not be fully functional. SYSTEM works
>>>>> SAVE-SYSTEM has not been adequately tested because of virus checkers
>>>>> that immediately delete the generated .EXE files.
>>>>>
>>>>> Groetjes Albert
>>>>>
>>>>> 1] Despite the name kernel32.dll is 64 bits software.
>>>>
>>>> Perhaps I don't understand what "native" means.  I thought that would be
>>>> a Forth that doesn't use an operating system.  Obviously that isn't
>>>> true.  What does "native" mean?
>>>
>>> Read the description and associate that with native in a ciforth context.
>>>
>>> In 2000 I had 2 configurations for a Linux Forth, one with c-calls
>>> for KEY and EMIT and READ-BLOCK and one native, i.e. direct Linux
>>> system calls. That stuck. Then there were similar MS-DOS and MS-Windows
>>> Forth's.
>>
>> I'm sorry, I don't follow what you are saying.  What is a c-call for
>> KEY/EMIT?  I'm lost here.
>
> It means:
>
> The assembler file contains
> -----------------
> ;  ***********
> ;  *   KEY   *
> ;  ***********
> ;
> N_KEY:
>         DC      3
>         DB      "KEY"
> KEY:
>         DC    KEY+HEADSIZE
>         DC    KEY+HEADSIZE
>         DC    0x0
>         DC    ACCEP
>         DC    N_KEY
>
>         CALL    c_key    ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>         PUSH    EAX
>         JMP NEXT
> ;
> ----------------
>
> A c-file contains
> -------------
>
> /* KEY */
> int c_key( void )     /* <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< */
> {
>   char key;
>   int i;
>   tty_keymode(&std_in);
>   i=read(0, &key, 1);
>   return key;
> }
>
> -----------
>
> Then the c-file is compiled using a c-compiler and the
> object is linked to the main assembler file.
>
> What else could it mean for Pete's sake?

I don't really know why you are talking about c-calls and Linux and now 
you are bringing Pete into it.

Why can't you just explain what you mean by "native" rather than trying 
to talk about all sorts of things that just complicate the picture?  Can 
you just give a definition of "native"?  Maybe in 20 words or less?


> All xxna versions, say normal versions, of ciforth contain a place
> where it says in the one assembler source file:
> -------------------------
>
> ;  ***********
> ;  *   KEY   *
> ;  ***********
> ;
>         ALIGN    8
> N_KEY:
>         DQ      3
>         DB      "KEY"
>         ALIGN    8
> KEY:
>         DQ    DOCOL
>         DQ    KEY+HEADSIZE
>         DQ    0x0
>         DQ    PACCEP
>         DQ    N_KEY
>         DQ    0
>         DQ    0
>
>         DQ      ONE, LIT, RAWIO, STTERM ; Do not wait for CR
>         DQ      ZERO, SPFET     ; Expect single key on stack
>         DQ      ZERO            ; Standard input
>         DQ      SWAP, ONE       ; Buffer and length
>         DQ      LIT, read, XOS
>         DQ      LDUP, QERRUR
>         DQ      ZEQU, LIT, -EPIPE, LAND, QERRUR ; Presumably end of pipe.
>         DQ      ONE, LIT, RAWIO, STTERM       ; Toggle back
>         DQ      SEMIS
> ;
>
> ---------------------
> (This is in fact Forth source code, inspectable by SEE).

Why would I want to inspect source code?  Is that the only way to 
understand what you are talking about?

-- 

Rick C

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

#56979

On Monday, April 10, 2017 at 1:15:18 AM UTC-5, rickman wrote:
> Why can't you just explain what you mean by "native"

By "native" he means USING LINUX SYSCALLS.

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

#56984

Julian Fondren <julian.fondren@gmail.com> writes:
> By "native" he means USING LINUX SYSCALLS.

Do you mean from asm code or what?  Usually I'd expect C wrappers around
those, in which case how are "c-calls" different?

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

#56992

On Monday, April 10, 2017 at 3:40:21 AM UTC-5, Paul Rubin wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
> > By "native" he means USING LINUX SYSCALLS.
> 
> Do you mean from asm code or what?

Yes.

> Usually I'd expect C wrappers around
> those, in which case how are "c-calls" different?

They're different in that they involve a C wrapper.

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

#56993

In article <57c92cc7-3bda-4afa-aa6b-adb917945f3a@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Monday, April 10, 2017 at 3:40:21 AM UTC-5, Paul Rubin wrote:
>> Julian Fondren <julian.fondren@gmail.com> writes:
>> > By "native" he means USING LINUX SYSCALLS.
>>
>> Do you mean from asm code or what?
>
>Yes.
>
>> Usually I'd expect C wrappers around
>> those, in which case how are "c-calls" different?
>
>They're different in that they involve a C wrapper.

E.g. KEY? may be implemented in C and linked in.
KEY? is not a wrapper of a system call, in fact it
calls several c-function from which is it not clear whether
they are wrappers. Hence the term c-call.
System call is a Unix term. Under windows it would be a
facility that is present under c:/windows/system32
(this definition holds for 64 bits too).

Native is a term I, a non-native English speaker, used to
make a distinction from the first implementation that
used libc calls.
In the context of ciforth a native Forth is a Forth that runs under
an Operating System, and is build without foreign libraries, but uses
the native facilities of the OS directly.
ciforth contains native implementations, stand alone implementations
and one other (the one using libc on linux).
The latter one was abandonned before the end of 2000. I checked,
it doesn't work anymore.

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]

#56999

On 4/10/2017 2:21 AM, Julian Fondren wrote:
> On Monday, April 10, 2017 at 1:15:18 AM UTC-5, rickman wrote:
>> Why can't you just explain what you mean by "native"
>
> By "native" he means USING LINUX SYSCALLS.

Great!  That was only 7 words!!!  I knew it was something simple like this.

So the distinction is that non-native uses portable code using C 
libraries and native uses direct operating system calls.  Can someone, 
in the same simple way, help me understand what the advantage of using 
OS calls would be?  Seems that C library calls would be portable and OS 
calls not, so there must be some advantage to using the direct OS calls. 
  Is there a big speed difference?  Is there something inherently bad 
about using C libraries?

-- 

Rick C

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web