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

Started byalbert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
First post2017-04-08 09:14 +0200
Last post2017-04-10 14:26 -0700
Articles 3 on this page of 23 — 9 participants

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 2 of 2 — ← Prev page 1 [2]

#57002

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2017-04-10 14:27 +0000
Message-ID<2017Apr10.162739@mips.complang.tuwien.ac.at>
In reply to#56999
rickman <gnuarm@gmail.com> writes:
>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.

It also demonstrates that Albert van der Horst uses words like Humpty
Dumpty; he ignores the commonly understood meaning (in c.l.f, "native"
means "without OS"), and uses his private meaning; but he's not alone
in this practice; e.g., Chuck Moore uses "cell" for what's otherwise
known as "word", and "Word" for something else, and OR for what others
call XOR.

>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?

There is, of course, the cost of the wrappers, and maybe also the cost
of the indirect call due to dynamic linking; OTOH, he still uses the
slow, old, and universal INT-based system call method, while the
wrappers use SYSENTER/SYSCALL where available (at least one of them
has been available on any new CPU for the last two decades or so), and
which is reportedly faster.  In the end, one would have to measure it.
For some system calls, calling the wrapper avoids entering the kernel
(i.e., significantly faster).
<http://www.win.tue.nl/~aeb/linux/lk/lk-4.html> says:

|John Stultz reports on an experiment where he measures gettimeofday()
|and finds 1.67 us for the int 0x80 way, 1.24 us for the sysenter way,
|and 0.88 us for the vsyscall [no kernel].

Looking around a little more, it looks like the source of that comes
from this thread:

<http://lkml.iu.edu/hypermail//linux/kernel/0401.3/1199.html>
<http://lkml.iu.edu/hypermail//linux/kernel/0401.3/1667.html>

Unfortunately, he does not mention the CPU he used; doing that
experiment again might give different results.

But I don't think that Albert van der Horst cares much about
real-world performance.

>Is there something inherently bad 
>about using C libraries?

I think he has his reasons, but they are not necessarily relevant for
other people.

- 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 2016: http://www.euroforth.org/ef16/

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

#57010

Fromalbert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
Date2017-04-10 20:05 +0200
Message-ID<ocghh9$m3u$1@cherry.spenarnc.xs4all.nl>
In reply to#56999
In article <ocg3a8$7dp$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>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.

Sorry but that was not entirely correct. See my other post.
Native doesn't apply merely to linux.

>
>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?

Ask Anton Ertl about the disadvantages of being dependant on outside
tooling.

That c-calls are more portable than OS-calls is a misconception.
Of course it is the political correct stand, so I will not start
to argue about it.

You make it seem that there is a best choice, but there are only
compromises and design goals.

There is something inherently bad about using libraries.
You need a linker. Then there is the link script. Every now and then
that must be rewritten. It is hard to have your memory map under control.
I want to have the memory map under control. That is a design goal.

With a c-library you don't have Forth, but a mix of Forth and some
other language.

There is more, but I hope that the above is sufficient to convince
you that my approach has merits.

Groetjes Albert

>Rick C
-- 
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]

#57018

Fromminforth@arcor.de
Date2017-04-10 14:26 -0700
Message-ID<9b4ccaf6-2199-4dd6-a70a-550c8d8a7f52@googlegroups.com>
In reply to#57010
Am Montag, 10. April 2017 20:04:34 UTC+2 schrieb Albert van der Horst:
> In article <ocg3a8$7dp$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
> >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.
> 
> Sorry but that was not entirely correct. See my other post.
> Native doesn't apply merely to linux.
> 
> >
> >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?
> 
> Ask Anton Ertl about the disadvantages of being dependant on outside
> tooling.
> 
> That c-calls are more portable than OS-calls is a misconception.
> Of course it is the political correct stand, so I will not start
> to argue about it.
> 
> You make it seem that there is a best choice, but there are only
> compromises and design goals.
> 
> There is something inherently bad about using libraries.
> You need a linker. Then there is the link script. Every now and then
> that must be rewritten. It is hard to have your memory map under control.
> I want to have the memory map under control. That is a design goal.
> 
> With a c-library you don't have Forth, but a mix of Forth and some
> other language.
> 
> There is more, but I hope that the above is sufficient to convince
> you that my approach has merits.
> 

May be I am too old meanwhile, but long ago I accepted that I am always standing on the shoulders of someone good before me. When I decline C libraries for whatever notions of independence or purism, I am standing on the shoulders of unknown CPU and assembler designers. Et cetera ad nauseam. So it is futile.

If C works, it works. If it is too slow, drop in some assembler lines. If it does not provide what the application needs, link with some suitable library. If you don't trust it, spend some precious lifetime to DIY...  ;-)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web