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

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

Why does the location of PAD move around?

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

Contents

  Why does the location of PAD move around? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-01 21:07 -0400
    Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-01 19:32 -0700
      Re: Why does the location of PAD move around? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-02 02:00 -0400
        Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 23:51 -0700
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-01 21:59 -1000
          Re: Why does the location of PAD move around? krishna.myneni@ccreweb.org - 2017-04-09 09:54 -0700
    Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 20:10 -0700
      Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-01 18:39 -1000
      Re: Why does the location of PAD move around? Mark Wills <markwills1970@gmail.com> - 2017-04-02 08:29 -0700
    Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:13 -0500
      Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 18:08 -0700
        Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-02 18:13 -0700
          Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 18:22 -0700
            Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-02 18:31 -0700
            Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 04:37 +0200
              Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 22:04 -0700
                Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 13:47 +0200
                  Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 10:53 -0500
                    Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 17:04 +0100
                    Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:00 +0200
                      Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 03:39 -0500
                        Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-05 19:17 +0100
              Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:44 -1000
            Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:35 -1000
            Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:38 -0500
            Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-05 11:25 +1000
              Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:23 -0700
                Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-07 14:26 +1000
                  Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-07 08:47 +0100
                    Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-08 10:25 +1000
                      Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-07 20:37 -0700
                      Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-08 12:42 +0100
                        Re: Why does the location of PAD move around? jason.songhurst@gmail.com - 2017-04-08 20:28 -0700
                          Re: Why does the location of PAD move around? Coos Haak <htrofhc@gmail.com> - 2017-04-09 13:47 +0200
                            Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 08:36 -1000
                          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-09 14:48 +0200
                        Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-10 10:31 +1000
                          Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-10 09:29 +0100
                          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-10 11:57 +0200
        Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 03:43 +0200
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:53 -1000
    Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-02 21:31 +1000
      Re: Why does the location of PAD move around? Coos Haak <htrofhc@gmail.com> - 2017-04-02 15:12 +0200
        Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-03 10:46 +1000
          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 03:31 +0200
            Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 19:14 -0700
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:55 -1000
            Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-04 11:06 +1000
              Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 12:54 +0100
                Re: Why does the location of PAD move around? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:27 +0000
                  Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 19:23 +0100
            Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-07 22:04 -0700
      Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 14:21 -0700
    Why does the location of PAD move around? Mark Wills <markwills1970@gmail.com> - 2017-04-02 08:28 -0700
      Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 13:47 -0700
        Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 15:13 -0700
          Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 18:55 -0700

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

#56643

On 4/2/17 3:43 PM, Albert van der Horst wrote:
> In article <87o9we5mc8.fsf@nightsong.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Multi-user systems.  Every terminal task has to have a PAD.
>>
>> What stops them from clobbering each other?  I'm presuming the tasks all
>> have the same HERE but maybe that's wrong.
>
> Yes, that is wrong. In most implementations you will note that HERE is
> in fact DP @ , where DP is a so called user variable. So the intent
> is there to duplicate DP for for every user (read task)
> Even if there are not several user compiling at different consoles,
> a task that is running in parallel, may do I/O. If it formats numbers
> it will use a small area at HERE (under PAD) that better be duplicaed
> for each task.

There's a big difference between the original model, which featured 
integrated code and data space, and the model used in embedded systems 
in which they are segregated. In the latter, HERE refers *only* to data 
space, not dictionary, whose pointer is usually named THERE and may not 
be available to user programs. PAD is in *data* space, remaining an 
offset from HERE but disconnected from DP.

In a multitasking system, each task *may* (depending on implementation) 
have its own dictionary and DP (returned by HERE or THERE depending). 
PAD, since it is defined with respect to HERE, is in data space in any 
case, and each task has its own.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#56583

Rod Pemberton wrote:
> Why does the location of PAD move around?
>
> TIB is allocated at a fixed location, but
> PAD's location is relative to HERE.
>
>
> Rod Pemberton

If it wasn't, it would have to be a fixed size.  Then you'd
have trouble deciding what size to make it.

Oops!  That's what ANS did :)

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

#56585

Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:

> Rod Pemberton wrote:
>> Why does the location of PAD move around?
>>
>> TIB is allocated at a fixed location, but
>> PAD's location is relative to HERE.
>>
>>
>> Rod Pemberton
> 
> If it wasn't, it would have to be a fixed size.  Then you'd
> have trouble deciding what size to make it.
> 
> Oops!  That's what ANS did :)

You mean that ANS prescribed a fixed size?
It didn't!
You might have used reverse logic ;-)

groet Coos

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

#56608

Coos Haak wrote:
> Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:
>
> > Rod Pemberton wrote:
> >> Why does the location of PAD move around?
> >>
> >> TIB is allocated at a fixed location, but
> >> PAD's location is relative to HERE.
> >>
> >>
> >> Rod Pemberton
> >
> > If it wasn't, it would have to be a fixed size.  Then you'd
> > have trouble deciding what size to make it.
> >
> > Oops!  That's what ANS did :)
>
> You mean that ANS prescribed a fixed size?
> It didn't!
> You might have used reverse logic ;-)
>
> groet Coos

It may as well be fixed.  Anyone with pretentions of writing a 'portable
program' will be going out their way not to exceed the minimums quoted.
To do otherwise is to limit your audience which would be self-defeating.

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

#56615

In article <obs624$61m$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
>Coos Haak wrote:
>> Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:
>>
>> > Rod Pemberton wrote:
>> >> Why does the location of PAD move around?
>> >>
>> >> TIB is allocated at a fixed location, but
>> >> PAD's location is relative to HERE.
>> >>
>> >>
>> >> Rod Pemberton
>> >
>> > If it wasn't, it would have to be a fixed size.  Then you'd
>> > have trouble deciding what size to make it.
>> >
>> > Oops!  That's what ANS did :)
>>
>> You mean that ANS prescribed a fixed size?
>> It didn't!
>> You might have used reverse logic ;-)
>>
>> groet Coos
>
>It may as well be fixed.  Anyone with pretentions of writing a 'portable
>program' will be going out their way not to exceed the minimums quoted.
>To do otherwise is to limit your audience which would be self-defeating.

Suppose I write a program that calibrates the speeds of a
certain type of msp430 chips. In view of this example the limiting
remark is almost ridicilous. If that program works on Linux
systems with a certain usb serial line driver, the last thing
I worry about if that I might use more bytes at PAD than are
available on e.g. a Forth that runs on the msp430 itself, where
this program would never run anyway.

All practical programs have to limit the audience to an extent,
to start with to people who find the program useful.
Otherwise one has painted oneself in the corner, writing
 example and toy programs, proofs of principle etc.
That is why authors of real programs are invited to write down the
environmental dependancies.

In the particular example of PAD one will find that it is a
non-issue with a capital N. The most simple solution is
ignore PAD.

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]

#56618

On Sunday, April 2, 2017 at 6:45:02 PM UTC-7, Albert van der Horst wrote:
> In article <obs624$61m$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
> >Coos Haak wrote:
> >> Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:
> >>
> >> > Rod Pemberton wrote:
> >> >> Why does the location of PAD move around?
> >> >>
> >> >> TIB is allocated at a fixed location, but
> >> >> PAD's location is relative to HERE.
> >> >>
> >> >>
> >> >> Rod Pemberton
> >> >
> >> > If it wasn't, it would have to be a fixed size.  Then you'd
> >> > have trouble deciding what size to make it.
> >> >
> >> > Oops!  That's what ANS did :)
> >>
> >> You mean that ANS prescribed a fixed size?
> >> It didn't!
> >> You might have used reverse logic ;-)
> >>
> >> groet Coos
> >
> >It may as well be fixed.  Anyone with pretentions of writing a 'portable
> >program' will be going out their way not to exceed the minimums quoted.
> >To do otherwise is to limit your audience which would be self-defeating.
> 
> Suppose I write a program that calibrates the speeds of a
> certain type of msp430 chips. In view of this example the limiting
> remark is almost ridicilous. If that program works on Linux
> systems with a certain usb serial line driver, the last thing
> I worry about if that I might use more bytes at PAD than are
> available on e.g. a Forth that runs on the msp430 itself, where
> this program would never run anyway.
> 
> All practical programs have to limit the audience to an extent,
> to start with to people who find the program useful.
> Otherwise one has painted oneself in the corner, writing
>  example and toy programs, proofs of principle etc.
> That is why authors of real programs are invited to write down the
> environmental dependancies.

I don't have any environmental dependencies in the novice-package (except that I assume the float-stack is not the data-stack, but everybody does that).

What good does it do to "write down the environmental dependencies?" If the compiler that you are trying to port your program to does have a small limit on PAD but you were expecting a large limit, what are you going to do about that? You can't rewrite the compiler.

Elizabeth Rather famously said: "Declare a dependency and forge ahead!"

This just results in vendor lock-in --- that was what the standard was supposed to prevent --- that was the problem in the 1980s when critics said: "If you've seen one Forth system, you've seen one Forth system."

I tried this: s" /PAD" environment?
VFX: 896
SwiftForth: 256

The ANS-Forth document says the minimum is 84. 

Anyway, all of this is nonsense anyway because any use of PAD is stupid --- discussing the technical details of PAD is like holding the bucket --- PAD should just be ignored as one of Elizabeth Rather's many failed attempts at programming.

> In the particular example of PAD one will find that it is a
> non-issue with a capital N. The most simple solution is
> ignore PAD.

Above you were saying to use PAD and declare an environmental dependency on the size of PAD --- now you are saying to ignore PAD --- well, are you going to hold the bucket or not?

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

#56644

On 4/2/17 2:46 PM, HAA wrote:
> Coos Haak wrote:
>> Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:
>>
>>> Rod Pemberton wrote:
>>>> Why does the location of PAD move around?
>>>>
>>>> TIB is allocated at a fixed location, but
>>>> PAD's location is relative to HERE.
>>>>
>>>>
>>>> Rod Pemberton
>>>
>>> If it wasn't, it would have to be a fixed size.  Then you'd
>>> have trouble deciding what size to make it.
>>>
>>> Oops!  That's what ANS did :)
>>
>> You mean that ANS prescribed a fixed size?
>> It didn't!
>> You might have used reverse logic ;-)
>>
>> groet Coos
>
> It may as well be fixed.  Anyone with pretentions of writing a 'portable
> program' will be going out their way not to exceed the minimums quoted.
> To do otherwise is to limit your audience which would be self-defeating.

Not at all. You just need to document the amount of PAD your program 
requires. Then it will be standard and run on any system with that much 
PAD available (which will probably be most).

Cheers,
Elizabeth


-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#56681

Elizabeth D. Rather wrote:
> On 4/2/17 2:46 PM, HAA wrote:
> > Coos Haak wrote:
> >> Op Sun, 2 Apr 2017 21:31:25 +1000 schreef HAA:
> >>
> >>> Rod Pemberton wrote:
> >>>> Why does the location of PAD move around?
> >>>>
> >>>> TIB is allocated at a fixed location, but
> >>>> PAD's location is relative to HERE.
> >>>>
> >>>>
> >>>> Rod Pemberton
> >>>
> >>> If it wasn't, it would have to be a fixed size.  Then you'd
> >>> have trouble deciding what size to make it.
> >>>
> >>> Oops!  That's what ANS did :)
> >>
> >> You mean that ANS prescribed a fixed size?
> >> It didn't!
> >> You might have used reverse logic ;-)
> >>
> >> groet Coos
> >
> > It may as well be fixed.  Anyone with pretentions of writing a 'portable
> > program' will be going out their way not to exceed the minimums quoted.
> > To do otherwise is to limit your audience which would be self-defeating.
>
> Not at all. You just need to document the amount of PAD your program
> requires. Then it will be standard and run on any system with that much
> PAD available (which will probably be most).
>
> Cheers,
> Elizabeth

'Standard' would be interrogating /PAD and aborting if it wasn't sufficient.
But who does that.

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

#56697

On 4/4/2017 02:06, HAA wrote:
> 'Standard' would be interrogating /PAD and aborting if it wasn't
> sufficient. But who does that.

The programmer. Not every feature needs to be programmatically checked. 
If you expect your code to be compiled by a variety of compilers, then 
testing your code on a variety of compilers will always be good practise.

I have recently been involved in a project that uses Intel's AVX. The 
assumption is that the binary will only run on processors that support 
AVX. No CPUID check is made for the feature, since things fly out of 
your nose when it's run on a processor that doesn't support it. The end 
result is the same, and the code is shorter.

-- 
Alex

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

#56719

Alex <alex@rivadpm.com> writes:
>the binary will only run on processors that support 
>AVX. No CPUID check is made for the feature, since things fly out of 
>your nose when it's run on a processor that doesn't support it.

This is machine language (for a proper architecture, not ARM), so no,
nothing flies out of your nose.  You get a properly defined illegal
instruction exception.

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

#56726

On 4/4/2017 17:27, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>> the binary will only run on processors that support
>> AVX. No CPUID check is made for the feature, since things fly out of
>> your nose when it's run on a processor that doesn't support it.
>
> This is machine language (for a proper architecture, not ARM), so no,
> nothing flies out of your nose.  You get a properly defined illegal
> instruction exception.
>
> - anton
>

I stand corrected on the lack of physiological effect.

-- 
Alex

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

#56847

On Monday, April 3, 2017 at 12:55:46 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/2/17 2:46 PM, HAA wrote:
> > It may as well be fixed.  Anyone with pretentions of writing a 'portable
> > program' will be going out their way not to exceed the minimums quoted.
> > To do otherwise is to limit your audience which would be self-defeating.
> 
> Not at all. You just need to document the amount of PAD your program 
> requires. Then it will be standard and run on any system with that much 
> PAD available (which will probably be most).

The problem is not the size of PAD or the fact that PAD changes its location occasionally --- the problem is that PAD is a global variable, and passing data between functions in global variables is bad programming --- when ANS-Forth made PAD standard, this made the entire Forth community appear to be ignoramuses who don't understand basic computer-science concepts.

Just abandon ANS-Forth --- it is stupid --- it is a purely negative contribution to Forth.

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

#56602

On Sunday, April 2, 2017 at 4:32:16 AM UTC-7, HAA wrote:
> Rod Pemberton wrote:
> > Why does the location of PAD move around?
> >
> > TIB is allocated at a fixed location, but
> > PAD's location is relative to HERE.
> >
> >
> > Rod Pemberton
> 
> If it wasn't, it would have to be a fixed size.  Then you'd
> have trouble deciding what size to make it.

My STRING-STACK.4TH holds the strings on the heap, so they can be any size. 

The clever part of my STRING-STACK.4TH is that I use copy-on-write (COW). Words such as DUP$ make a copy of the address/count, which is called a "derivative." If you give a derivative to a consumer, such as .$ etc., then it consumes the derivative without needing to make a new copy of the string. If you give a derivative to a mutator however, then the derivative has to be converted into a "unique" meaning that a copy is made. If you give a unique to a mutator, then the string-stack has to be searched for derivatives which are changed into uniques, so the first unique can be mutated without messing up the derivatives.

All in all, my STRING-STACK.4TH is very efficient. Quite a lot of the time, you get by without doing any string copying (because this involves an ALLOCATE and a CMOVE, and will eventually involve a FREE) --- all that is copied are references, which is very fast.

> Oops!  That's what ANS did :)

All in all, I think that my STRING-STACK.4TH is the best Forth code that has ever been written for handling strings. :)

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

#56589

Just redefine it if you don't like it. This is forth after all. 

Create pad 256 chars allot 

Boom!

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

#56601

On Sunday, April 2, 2017 at 8:28:27 AM UTC-7, Mark Wills wrote:
> Just redefine it if you don't like it. This is forth after all. 
> 
> Create pad 256 chars allot 
> 
> Boom!

Mark --- you're making a fool out of yourself --- I expected to see Andrew Haley and Elizabeth Rather step forward to hold the bucket, but you are a bit smarter than that (or so I thought).

I wrote STRING-STACK.4TH (you have a copy) --- Boom! --- this works well for string storage.

Passing data between functions --- as done in PAD --- is very bad programming. This was done in the 1970s because of extreme RAM shortages. Doing this today is stupid. The fact that PAD is in the ANS-Forth standard makes the entire Forth community look stupid --- this is why Forthers have a reputation for being ignoramuses who don't understand the most basic concepts of computer-science, and are unwilling to learn.

The fact that PAD changes its location occasionally is irrelevant --- PAD is stupid standing still, PAD is stupid moving around, PAD is stupid everywhere! --- this is Elizabeth Rather's sub-novice level of programming.

STRING-STACK.4TH is actually some of the best Forth programming I've done in several years --- I'm pretty proud of it --- this is a concept that the ANS-Forth cult hate and fear, because they don't write Forth code that they can be proud of. The ANS-Forth cult's "expertise" is granted to them by Elizabeth Rather in exchange for their unquestioning loyalty --- they are not allowed to write code that they could be proud of, because doing so necessarily involves working around ANS-Forth's idiotic design decisions, which tends to shine a spotlight on the fact that Elizabeth Rather is not a programmer.

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

#56603

On Sunday, April 2, 2017 at 1:47:43 PM UTC-7, hughag...@gmail.com wrote:
> Passing data between functions --- as done in PAD --- is very bad programming. 

This was a typo. I meant:
"Passing data between functions in global variables --- as done in PAD --- is very bad programming."

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

#56616

On Sunday, April 2, 2017 at 3:13:19 PM UTC-7, hughag...@gmail.com wrote:
> Passing data between functions in global variables --- as done in PAD --- is very bad programming.

I've already covered this elsewhere, but the <# buffer is another global variable that is used for passing data between functions --- another blunder of ANS-Forth!

Alex McDonald was saying (likely he still does say) that there is a bug in my SCIENTIFIC and ENGINEERING words because of this:

12345.6789e engineering  ok-2 
type 12.345679e32 ok 

I fixed the bug though! Here is the test again, working this time:

12345.6789e engineering  ok-2 
type 12.345679e3  ok

Whenever I run into bugs, the bugs are almost always in ANS-Forth and/or in the ANS-Forth compiler (VFX in this case) --- it is very rare for me to have bugs in my own code.

This is how I fixed the bug:
---------------------------------------------------------------------------

\ ******
\ ****** This is <# # #> etc. rewritten to use <CSTR so there aren't conflicts.
\ ******

: big-um/mod ( ud u -- remainder Dquotient )
    >r  2dup                            \ -- ud ud
    dup 0< if  -1  else  1  then        \ -- ud ud multiplier       \ this assures a positive intermediate value in M*/
    r@ m*/  2tuck                       \ -- Dquotient ud Dquotient
    r> 1 m*/                            \ -- Dquotient ud Dquotient*divisor
    d-                                  \ -- Dquotient Dremainder    
    abort" *** BIG-UM/MOD remainder overflowed ***" 
    -rot ;
    
here ," 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
1+ constant digits

: <# ( -- )
    <cstr ;
    
: hold ( char -- )    
    char+cstr ;
    
: sign ( n -- )    
    0< if  [char] - hold  then ;
    
: # ( ud1 -- ud2 )    
    base @  big-um/mod                  \ -- remainder Dquotient
    rot digits + c@ hold ;
    
: #s ( ud1 -- 0. )
    begin  #  2dup or 0= until ;
    
: #> ( ud -- adr cnt )    
    2drop                               \ --
    cstr> count                         \ -- adr cnt
    2dup reverse-str ;

------------------------------------------------------------------------

[toc] | [prev] | [standalone]

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

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

csiph-web