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

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

Forth without integer data stack. It is even better!

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

Contents

  Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-15 19:22 -0700
    Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-15 20:42 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-16 02:13 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 12:09 -0700
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 15:33 -0700
            Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 16:18 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:22 +0000
          Re: Forth without integer data stack. It is even better! "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-19 03:38 -0400
          Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-19 17:21 -0700
            Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-19 21:07 -0700
    Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-08-16 06:52 +0000
    Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-16 14:19 +0200
      Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-16 05:52 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 14:42 -0700
          Re: Forth without integer data stack. It is even better! dylan.mcnamee@gmail.com - 2015-09-21 12:02 -0700
            Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-22 00:34 +0200
        Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-09-26 19:18 +0000
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 12:08 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-16 15:17 -0400
    Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 13:47 +0000
      Re: Forth without integer data stack. It is even better! Paul Rubin <no.email@nospam.invalid> - 2015-08-16 07:54 -0700
        Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 15:04 +0000
          Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 23:56 +0200
            Re: Forth without integer data stack. It is even better! Richard Owlett <rowlett@cloud85.net> - 2015-08-17 05:57 -0500
              Re: Forth without integer data stack. It is even better! Coos Haak <chforth@hccnet.nl> - 2015-08-17 13:52 +0200
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:00 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-17 12:03 +0000
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:29 -0700
                  Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:10 +0000
            Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 14:50 +0200
              Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 19:42 +0200
                Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 23:16 +0200
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:00 +0200
                    Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:17 +0200
                      Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-18 10:12 +0200
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:12 -0700
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:35 -0700
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-26 21:23 +0200
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 09:55 -0700
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 10:00 -0700
      Re: Forth without integer data stack. It is even better! mhx@iae.nl - 2015-08-16 08:37 -0700
    Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 18:28 -0700
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-17 20:17 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 00:49 -0400
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 23:00 -0700
            Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 06:25 +0000
              Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 08:39 -0700
                Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 12:09 -0400
    Re: Forth without integer data stack. It is even better! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-08-18 01:31 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-12 17:47 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-12 18:06 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#41337

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> perf stat gforth-fast -e "fvariable x x s>f x f! \
> : foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop ; \

What happens if the address of x doesn't fit in the mantissa of a single
float, so you lose precision converting it to and from a float?

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

#41338

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> perf stat gforth-fast -e "fvariable x x s>f x f! \
>> : foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop ; \
>
>What happens if the address of x doesn't fit in the mantissa of a single
>float, so you lose precision converting it to and from a float?

That would certainly be a problem.  AFAIK for now the MMUs on AMD64
CPUs map only 48 virtual bits to physical bits (the top 17 bits must
be all 0 or all 1), so on that architecture that problem cannot
happen, yet.  You can check this by looking at the "address sizes"
line in /proc/cpuinfo on Linux.  I guess in the long run one would
have to use long doubles.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41346

Anton Ertl wrote:

> Paul Rubin <no.email@nospam.invalid> writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> perf stat gforth-fast -e "fvariable x x s>f x f! \
>>> : foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop
>>> : ; \
>>
>>What happens if the address of x doesn't fit in the mantissa of a single
>>float, so you lose precision converting it to and from a float?
> 
> That would certainly be a problem.  AFAIK for now the MMUs on AMD64
> CPUs map only 48 virtual bits to physical bits (the top 17 bits must
> be all 0 or all 1), so on that architecture that problem cannot
> happen, yet.  You can check this by looking at the "address sizes"
> line in /proc/cpuinfo on Linux.  I guess in the long run one would
> have to use long doubles.

Pointers are indeed less of a problem; the bigger problem is code that 
depends on wraparound and uses all 64 bits for the integers.

For a Forth on the GPU, which processes floats most of the time anyhow, and 
where you want a really small engine, this concept should be kept in mind.

The concept as such reminds me on early home computer BASIC implementations 
(like the one from Microsoft), where all numbers were floats.

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

#41351

Bernd Paysan wrote:
> [snip]
>
> The concept as such reminds me on early home computer BASIC implementations
> (like the one from Microsoft), where all numbers were floats.
>

???
I don't recall any BASIC where I, J, K, L, M, N were not integers.

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

#41352

Op Mon, 17 Aug 2015 05:57:13 -0500 schreef Richard Owlett:

> Bernd Paysan wrote:
>> [snip]
>>
>> The concept as such reminds me on early home computer BASIC implementations
>> (like the one from Microsoft), where all numbers were floats.
>>
> 
> ???
> I don't recall any BASIC where I, J, K, L, M, N were not integers.

That's Fortran. On the ZX Spectrum, internally all numbers were 5 byte long
floating point. Integers occupied 2 bytes of this space and for faster
processing.

groet Coos

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

#41353

On Monday, 17 August 2015 12:52:58 UTC+1, Coos Haak  wrote:
> Op Mon, 17 Aug 2015 05:57:13 -0500 schreef Richard Owlett:
> 
> > Bernd Paysan wrote:
> >> [snip]
> >>
> >> The concept as such reminds me on early home computer BASIC implementations
> >> (like the one from Microsoft), where all numbers were floats.
> >>
> > 
> > ???
> > I don't recall any BASIC where I, J, K, L, M, N were not integers.
> 
> That's Fortran. On the ZX Spectrum, internally all numbers were 5 byte long
> floating point. Integers occupied 2 bytes of this space and for faster
> processing.
> 
> groet Coos

Same on the TI. On the TI they're Radix 100 format.

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

#41354

Richard Owlett <rowlett@cloud85.net> writes:
>Bernd Paysan wrote:
>> [snip]
>>
>> The concept as such reminds me on early home computer BASIC implementations
>> (like the one from Microsoft), where all numbers were floats.
>>
>
>???
>I don't recall any BASIC where I, J, K, L, M, N were not integers.

On Microsoft Basic (e.g., on the Commodore 64) these all were FP.  You
could get integer variables by (IIRC) appending %, i.e., I%, but I
think computation was always done in FP.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41355

On Monday, 17 August 2015 13:10:00 UTC+1, Anton Ertl  wrote:
> Richard Owlett <rowlett@cloud85.net> writes:
> >Bernd Paysan wrote:
> >> [snip]
> >>
> >> The concept as such reminds me on early home computer BASIC implementations
> >> (like the one from Microsoft), where all numbers were floats.
> >>
> >
> >???
> >I don't recall any BASIC where I, J, K, L, M, N were not integers.
> 
> On Microsoft Basic (e.g., on the Commodore 64) these all were FP.  You
> could get integer variables by (IIRC) appending %, i.e., I%, but I
> think computation was always done in FP.
> 
> - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

That's how I remember it, too. The only exception I can think of
is/was the UK made BBC Model B. On that machine you could declare
integer variables with a % - they ran much faster - it had a really
fast BASIC for its day.

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

#41369

Mark Wills <markwills1970@gmail.com> writes:
>That's how I remember it, too. The only exception I can think of
>is/was the UK made BBC Model B. On that machine you could declare
>integer variables with a % - they ran much faster - it had a really
>fast BASIC for its day.

BBC Basic was not from Microsoft.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41356

On 16/08/15 23:56, Bernd Paysan wrote:
> Anton Ertl wrote:
>
>> Paul Rubin <no.email@nospam.invalid> writes:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> perf stat gforth-fast -e "fvariable x x s>f x f! \
>>>> : foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop
>>>> : ; \
>>>
>>> What happens if the address of x doesn't fit in the mantissa of a single
>>> float, so you lose precision converting it to and from a float?
>>
>> That would certainly be a problem.  AFAIK for now the MMUs on AMD64
>> CPUs map only 48 virtual bits to physical bits (the top 17 bits must
>> be all 0 or all 1), so on that architecture that problem cannot
>> happen, yet.  You can check this by looking at the "address sizes"
>> line in /proc/cpuinfo on Linux.  I guess in the long run one would
>> have to use long doubles.
>
> Pointers are indeed less of a problem; the bigger problem is code that
> depends on wraparound and uses all 64 bits for the integers.
>
> For a Forth on the GPU, which processes floats most of the time anyhow, and
> where you want a really small engine, this concept should be kept in mind.

Yes, absolutely, I'm with you here. This could be a really practical 
utilization.
At the moment my CPU is doing things, I'd rather have done by the GPU. 
That's what they're for :-)
On the Mac using a Forth to OpenCL-C converter is perhaps a first step.
Run the conversion through the OpenCL compiler and send the result to 
the GPU, all with the appropriate calls.
I recall you were interested in an OpenCL interface?

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

#41357

Roelf Toxopeus wrote:
> I recall you were interested in an OpenCL interface?

I'm now more interested in Vulkan's variant of OpenCL, where you can create 
the intermediate virtual machine code (SPIR-V) directly.  This would be fun 
- the host has the compiler, you use a tiny "sort-of umilical" Forth to 
compile GPU compute cores - not really umbilical, but you can incrementally 
change your code, and recompile the virtual machine code each time you 
updated it.

SPIR-V can be used both for shaders and for compute cores.

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

#41358

On 17/08/15 19:42, Bernd Paysan wrote:
> Roelf Toxopeus wrote:
>> I recall you were interested in an OpenCL interface?
>
> I'm now more interested in Vulkan's variant of OpenCL, where you can create
> the intermediate virtual machine code (SPIR-V) directly.  This would be fun
> - the host has the compiler, you use a tiny "sort-of umilical" Forth to
> compile GPU compute cores - not really umbilical, but you can incrementally
> change your code, and recompile the virtual machine code each time you
> updated it.
>
> SPIR-V can be used both for shaders and for compute cores.
>

That sounds quite interesting and very useful. The "sort of umbilical" 
Forth was something I imagined for the OpenCL interface.
It seems on my platform they choose to go Metal rather than Vulcan.

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

#41359

Roelf Toxopeus wrote:

> On 17/08/15 19:42, Bernd Paysan wrote:
>> Roelf Toxopeus wrote:
>>> I recall you were interested in an OpenCL interface?
>>
>> I'm now more interested in Vulkan's variant of OpenCL, where you can
>> create
>> the intermediate virtual machine code (SPIR-V) directly.  This would be
>> fun - the host has the compiler, you use a tiny "sort-of umilical" Forth
>> to compile GPU compute cores - not really umbilical, but you can
>> incrementally change your code, and recompile the virtual machine code
>> each time you updated it.
>>
>> SPIR-V can be used both for shaders and for compute cores.
> 
> That sounds quite interesting and very useful. The "sort of umbilical"
> Forth was something I imagined for the OpenCL interface.

Yes, but it's quite likely working better if you don't have to produce 
something with valid OpenCL syntax as intermediate.

> It seems on my platform they choose to go Metal rather than Vulcan.

Tough luck.  Microsoft wants DirectX 12, but at least they don't control the 
drivers from AMD, NVidia and Intel, so you'll still get Vulkan.  Linux and 
Android are openly embracing it anyhow, but Apple with their control freak 
mentality want to be different.

However, Vulkan's unique strength is actually SPIR-V...

http://streamcomputing.eu/blog/2015-05-21/8-reasons-why-spir-v-makes-a-big-difference/

Given that Apple is part of the Khronos group, and did benefit from having 
OpenGL, and that their market share is between 10 and 20% depending on 
platform (mobile phones 20%, desktops around 10%), they don't have the power 
for "my way or no way".

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

#41360

Bernd Paysan wrote:
> Given that Apple is part of the Khronos group, and did benefit from having
> OpenGL, and that their market share is between 10 and 20% depending on
> platform (mobile phones 20%, desktops around 10%), they don't have the
> power for "my way or no way".

There can be another reason for not saying that they support Vulkan: Vulkan 
isn't ready, and they want people to use Metal for low-overhead 3D graphics, 
which is currently a competitive edge over Android - Marshmallow will 
unlikely have Vulkan (Vulkan is not finished yet), so we'll have to wait 
until Android Nutella (or whatever the name of Android N will be ;-).

So when they would announce now that they will be backing Vulkan, and Metal 
is just an intermediate API, people will wait for Vulkan, and not port to 
Metal, leveling the field.

I'm also not sure about the strength of Microsoft - even with the free 
update to Windows 10, most of their customers are conservative, and will 
stay with Windows 7.  Vulkan will be available to Windows 7 (it's just a 
driver update, Vulkan is tugged on the side of OpenGL in the drivers), but 
DirectX 12 won't.  That means Vulkan's customer base will be quickly much 
larger than DirectX 12.

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

#41367

On 18/08/15 01:17, Bernd Paysan wrote:
> Bernd Paysan wrote:
>> Given that Apple is part of the Khronos group, and did benefit from having
>> OpenGL, and that their market share is between 10 and 20% depending on
>> platform (mobile phones 20%, desktops around 10%), they don't have the
>> power for "my way or no way".
>
> There can be another reason for not saying that they support Vulkan: Vulkan
> isn't ready, and they want people to use Metal for low-overhead 3D graphics,
> which is currently a competitive edge over Android - Marshmallow will
> unlikely have Vulkan (Vulkan is not finished yet), so we'll have to wait
> until Android Nutella (or whatever the name of Android N will be ;-).
>
> So when they would announce now that they will be backing Vulkan, and Metal
> is just an intermediate API, people will wait for Vulkan, and not port to
> Metal, leveling the field.
>

Yes, sounds plausible. Apple obviously has a lot of experience in 
phasing in/out one technology for another (68000-PPC-Intel, 
Classic-Carbon-Cocoa, ObjC-Swift, etc.). But they can also merciless 
ditch a technology introduced a year before (64bitCarbon most prominent).

Meanwhile there's a bit of pressure upon them regarding the problems 
encountered with the graphics GUI handling since 10.7 leading to some 
quite embarrassing results. Speculations are that's another reason for 
introducing Metal now (on 10.11).

Until I got Job's job, I'll never have it the way I want ;-)

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

#42198

You mean compiling from Forth source to SPIR-V code ?

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

#42199

Bernd,

You mean compiling from Forth source to SPIR-V code ?

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

#42202

Александр Стадниченко wrote:

> Bernd,
> 
> You mean compiling from Forth source to SPIR-V code ?

Yes, that's the idea.  At least something Forth-like like PAF.

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

#42211

Bernd,

It is great idea. You plans to work on it? It is very interesting to me. I will watch closely your work.

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

#42212

Whether as you think there is a sense to compile to native GPU code directly?

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web