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

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

I'm so conflicted...

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

Contents

  I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-11 03:47 -0800
    I'm so conflicted... foxaudioresearch@gmail.com - 2016-11-11 04:37 -0800
    Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-11 05:29 -0800
      Re: I'm so conflicted... JUERGEN <epldfpga@aol.com> - 2016-11-11 05:33 -0800
      Re: I'm so conflicted... JUERGEN <epldfpga@aol.com> - 2016-11-11 05:35 -0800
      Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-11 20:02 -0500
        Re: I'm so conflicted... jim <anon@example.com> - 2016-11-12 10:59 +0000
          Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-12 11:21 -0500
            Re: I'm so conflicted... jim <anon@example.com> - 2016-11-12 21:30 +0000
              Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-12 23:18 -0500
                Re: I'm so conflicted... jim <anon@example.com> - 2016-11-13 12:28 +0000
                  Re: I'm so conflicted... Paul Rubin <no.email@nospam.invalid> - 2016-11-13 10:50 -0800
                    Re: I'm so conflicted... jim <anon@example.com> - 2016-11-13 19:14 +0000
                  Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-13 23:11 -0500
                    Re: I'm so conflicted... jim <anon@example.com> - 2016-11-14 09:44 +0000
          Re: I'm so conflicted... "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-20 01:51 +0000
        Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-12 10:32 -0800
          Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-12 13:52 -0500
            Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-12 11:55 -0800
              Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-12 23:19 -0500
                Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-13 18:16 -0800
                  Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-13 23:14 -0500
                    Re: I'm so conflicted... jim <anon@example.com> - 2016-11-14 09:51 +0000
                    Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-14 04:04 -0800
                      Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-15 03:11 -0800
                        Re: I'm so conflicted... "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-20 23:50 +0000
          Re: I'm so conflicted... albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 20:11 +0100
    Re: I'm so conflicted... "HAA" <someone@microsoft.com> - 2016-11-12 00:34 +1100
    Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-11 16:19 -0800
      Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-12 10:34 -0800
        Re: I'm so conflicted... november.nihal@gmail.com - 2016-11-12 12:35 -0800
          Re: I'm so conflicted... "Elizabeth D. Rather" <erather@forth.com> - 2016-11-12 11:46 -1000
            Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-12 15:23 -0800
              Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-12 18:13 -0800
              Re: I'm so conflicted... rickman <gnuarm@gmail.com> - 2016-11-12 23:23 -0500
                Re: I'm so conflicted... "Elizabeth D. Rather" <erather@forth.com> - 2016-11-12 20:55 -1000
              Re: I'm so conflicted... "Elizabeth D. Rather" <erather@forth.com> - 2016-11-12 20:46 -1000
                Re: I'm so conflicted... Paul Rubin <no.email@nospam.invalid> - 2016-11-13 01:06 -0800
                  Re: I'm so conflicted... Mikael Nordman <oh2aun@gmail.com> - 2016-11-13 12:59 -0800
                    Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-13 18:27 -0800
                      Re: I'm so conflicted... Mikael Nordman <oh2aun@gmail.com> - 2016-11-13 20:34 -0800
                Re: I'm so conflicted... Howerd <howerdo@yahoo.co.uk> - 2016-11-13 17:56 -0800
                  Re: I'm so conflicted... "HAA" <someone@microsoft.com> - 2016-11-14 14:53 +1100
                  Re: I'm so conflicted... "Elizabeth D. Rather" <erather@forth.com> - 2016-11-13 22:04 -1000
            Re: I'm so conflicted... albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 10:51 +0100
    Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-14 03:10 -0800
      Re: I'm so conflicted... "HAA" <someone@microsoft.com> - 2016-11-15 01:03 +1100
        Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-14 07:31 -0800
          Re: I'm so conflicted... foxaudioresearch@gmail.com - 2016-11-14 13:29 -0800
            Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-15 03:02 -0800
              Re: I'm so conflicted... albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 13:39 +0100
          Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-15 18:22 -0800
            Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-16 01:32 -0800
              Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-16 13:00 -0800
                Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-16 13:04 -0800
                Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-16 13:42 -0800
                  Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-17 12:28 -0800
                    Re: I'm so conflicted... Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-17 22:14 -0800
                    Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-19 15:01 -0800
                      Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-19 16:55 -0800
                        Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-20 10:36 -0800
                          Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-20 10:43 -0800
                          Re: I'm so conflicted... Paul Rubin <no.email@nospam.invalid> - 2016-11-20 11:15 -0800
                            Re: I'm so conflicted... Mark Wills <markwills1970@gmail.com> - 2016-11-20 13:57 -0800
                          Re: I'm so conflicted... Walter Banks <walter@bytecraft.com> - 2016-11-28 13:26 -0500
            Re: I'm so conflicted... Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-11-16 10:25 +0000
              Re: I'm so conflicted... hughaguilar96@gmail.com - 2016-11-16 12:33 -0800

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

#52605

On Monday, November 14, 2016 at 4:27:59 AM UTC+2, Howerd wrote:
> On Sunday, 13 November 2016 21:59:37 UTC+1, Mikael Nordman  wrote:
> > On Sunday, November 13, 2016 at 11:06:17 AM UTC+2, Paul Rubin wrote:
> > > "Elizabeth D. Rather"  writes:
> > > > In polyFORTH, PAD was an offset from HERE...  having an individual PAD
> > > > for every task *avoids* re-entrancy problems... It is intended as a
> > > > convenience for user programs, to provide a re-usable temporary buffer
> > > > under the sole control of the application.
> > > 
> > > Why not let the user program ALLOT a chunk of memory for such purposes
> > > if it wants?  How much memory did those systems typically have?  I guess
> > > things are different now in that small systems have flash program
> > > memory, often leaving them with less ram (formerly called core) than the
> > > old small systems had.  I think of Forth on a MSP430G2553 (512 bytes
> > > ram) or even an Arduino (2k ram) and go "wow, 80 bytes for PAD is pretty
> > > costly".  Of course it's possible to declare an environmental dependency
> > > and shrink or eliminate PAD, but I don't understand why it's there in
> > > the first place.
> > 
> > This is what I do in FlashForth. Each task has a PAD of size zero at the end of its user area. It is up to the programmer to allot space for each instance of PAD.
> > 
> > PAD is there because of some historical reasons. I have never needed it myself.
> 
> Hi Michael,
> 
> In a non multi-user system, PAD is just a label for the end of the USER area.
> Using PAD without an ALLOT ( in USER memory ) is just a way of using a part of memory before it gets  ALLOTTed  , so there is no need to free it later.

In FlashForth PAD is a USER area buffer. I can see some uses for that.
The default size of zero is a compromise to optimize ram usage on microcontrollers. For instance the PIC14K50 USB chip has 175 bytes of 
free memory on a empty FlashForth system.

For each created task you need to allot the PAD area as needed.  

> 
> Do you have to  ALLOT  a  PAD  if you want to use number formatting words?

No, the number formatting words use the memory below PAD which happens to be at the end of TIB. # builds the string backwards in memory.
There is a small extra part in TIB for use by <# # #>
 
> What happens if you forget?

In that case PAD would collide with your VARIABLES or any other ALLOTED memory
that hits the same memory space.
Code goes into flash so there is no conflict there.

Mikael

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

#52595

On Sunday, 13 November 2016 07:46:58 UTC+1, Elizabeth D. Rather  wrote:
> On 11/12/16 1:23 PM, Howerd wrote:
> > On Saturday, 12 November 2016 22:46:10 UTC+1, Elizabeth D. Rather  wrote:
> >> On 11/12/16 10:35 AM, gmail.com wrote:
> >>>
> >>>> Could you enlighten me as to why you think "PAD is a bad idea"?
> >>>> I am assuming a Forth system where PAD is an array of USER variables...
> >>>>
> >>>> Best regards,
> >>>> Howerd
> >>>
> >>> I thought that PAD was the address of a scratch area used for temporary storage!
> >>
> >> Correct. According to Forth212, the word PAD returns the address of "a
> >> transient region that can be used to hold data for intermediate
> >> processing." In most multi-user systems, each user has one, so there is
> >> no re-entrancy problem. Most multi-user systems *also* have a "user
> >> area" where user variables (such as BASE, pointer returned by HERE,
> >> etc.) reside, but it is not in or near PAD in my experience.
> >>
> >> Cheers,
> >> Elizabeth
> >>
> >> --
> >> ==================================================
> >> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> >> FORTH Inc.                         +1 310.999.6784
> >> 5959 West Century Blvd. Suite 700
> >> Los Angeles, CA 90045
> >> http://www.forth.com
> >>
> >> "Forth-based products and Services for real-time
> >> applications since 1973."
> >> ==================================================
> >
> > Hi Elizabeth,
> >
> > Yes, you are right : in a multi-user system like SwiftForth PAD
> > is defined as an offset from  HERE  which is nowhere near the USE
> > variables.
> >
> > In an embedded system ( e.g. polyForth, chipForth and SwiftX )
> > PAD  is usually tacked onto the end of the USER variables.
> >
> > In either case each task has its own  PAD  area, so I am curious
> > to know what sort of re-entrancy problems this can cause - I am
> > not aware of any.
> >
> > Best regards,
> > Howerd
> 
> In polyFORTH, PAD was an offset from HERE as in SwiftForth. SwiftX does 
> not really support multiple users with individual dictionaries, although 
> there are multiple tasks using a simpler implementation. I don't at the 
> moment recall exactly where it is for SwiftX. However, having an 
> individual PAD for every task *avoids* re-entrancy problems, rather than 
> causing them. All standards AFAIK include the prohibition embedded in 
> Forth94 that the System may not use PAD. It is intended as a convenience 
> for user programs, to provide a re-usable temporary buffer under the 
> sole control of the application.
> 
> When I think of "re-entrancy problems" I assume a multi-tasking 
> environment, and the definition of PAD is explicitly designed to avoid 
> any such.
> 
> Cheers,
> Elizabeth
> 
> -- 
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045
> http://www.forth.com
> 
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Hi Elizabeth,

I stand corrected, again ;-)

polyFORTH ISD-4  MSD  Disk 1  Shadows  1988 Mar 14  
================================================== 
CODE HERE ( - a)   H U) PUSH   NEXT                             
CODE PAD ( - a)   H U) 0 MOV   34 # 0 ADD   0 PUSH   NEXT      

SwiftX ( 2016 )
==============
TARGET
: PAD ( -- c-addr )   HERE |NUM| + ;

chipForth ( 1988 )
==================
2 +USER 'TAB   2 +USER 'PAGE  2 +USER 'MARK   32 + 0 +USER PAD   DROP 

So chipForth is the only Forth, Inc. system that puts PAD at the end of the USER variables. Because the chipForth target system is not multi-user.

Since SwiftX provides target versions of QUIT , the targets are multi-user, so  PAD is defined as an offset from  HERE . 

Either way, since  H ( used by  HERE )  is a  USER  variable,  PAD  is always in task specific memory. 

So the rule is, if you are using a word that uses  PAD  , such as (.) , don't expect PAD to be the same after you call it as before.

But there are no re-entrancy issues, in the sense of  PAD  being used by multiple tasks at the same time, because each task has it's own PAD .

Best regards,
Howerd

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

#52600

Howerd wrote:
> ...
> So the rule is, if you are using a word that uses  PAD  , such as (.) , don't expect
> PAD to be the same after you call it as before.

You shouldn't be using PAD for that :)

Classically PAD was xx bytes above HERE.  Numeric output functions used the
space *below* PAD.  PAD is intended as a 'short term' buffer (in the same way
as the PNO buffer is short term).  Don't do anything that alters HERE and PAD
is reasonably safe.

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

#52608

On 11/13/16 3:56 PM, Howerd wrote:
> On Sunday, 13 November 2016 07:46:58 UTC+1, Elizabeth D. Rather  wrote:
>> On 11/12/16 1:23 PM, Howerd wrote:
>>> On Saturday, 12 November 2016 22:46:10 UTC+1, Elizabeth D. Rather  wrote:
>>>> On 11/12/16 10:35 AM, gmail.com wrote:
>>>>>
>>>>>> Could you enlighten me as to why you think "PAD is a bad idea"?
>>>>>> I am assuming a Forth system where PAD is an array of USER variables...
>>>>>>
>>>>>> Best regards,
>>>>>> Howerd
>>>>>
>>>>> I thought that PAD was the address of a scratch area used for temporary storage!
>>>>
>>>> Correct. According to Forth212, the word PAD returns the address of "a
>>>> transient region that can be used to hold data for intermediate
>>>> processing." In most multi-user systems, each user has one, so there is
>>>> no re-entrancy problem. Most multi-user systems *also* have a "user
>>>> area" where user variables (such as BASE, pointer returned by HERE,
>>>> etc.) reside, but it is not in or near PAD in my experience.
>>>>
>>>> Cheers,
>>>> Elizabeth
>>>>
>>>> --
>>>> ==================================================
>>>> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>>>> FORTH Inc.                         +1 310.999.6784
>>>> 5959 West Century Blvd. Suite 700
>>>> Los Angeles, CA 90045
>>>> http://www.forth.com
>>>>
>>>> "Forth-based products and Services for real-time
>>>> applications since 1973."
>>>> ==================================================
>>>
>>> Hi Elizabeth,
>>>
>>> Yes, you are right : in a multi-user system like SwiftForth PAD
>>> is defined as an offset from  HERE  which is nowhere near the USE
>>> variables.
>>>
>>> In an embedded system ( e.g. polyForth, chipForth and SwiftX )
>>> PAD  is usually tacked onto the end of the USER variables.
>>>
>>> In either case each task has its own  PAD  area, so I am curious
>>> to know what sort of re-entrancy problems this can cause - I am
>>> not aware of any.
>>>
>>> Best regards,
>>> Howerd
>>
>> In polyFORTH, PAD was an offset from HERE as in SwiftForth. SwiftX does
>> not really support multiple users with individual dictionaries, although
>> there are multiple tasks using a simpler implementation. I don't at the
>> moment recall exactly where it is for SwiftX. However, having an
>> individual PAD for every task *avoids* re-entrancy problems, rather than
>> causing them. All standards AFAIK include the prohibition embedded in
>> Forth94 that the System may not use PAD. It is intended as a convenience
>> for user programs, to provide a re-usable temporary buffer under the
>> sole control of the application.
>>
>> When I think of "re-entrancy problems" I assume a multi-tasking
>> environment, and the definition of PAD is explicitly designed to avoid
>> any such.
>>
>> Cheers,
>> Elizabeth
>>
>> --
>> ==================================================
>> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>> FORTH Inc.                         +1 310.999.6784
>> 5959 West Century Blvd. Suite 700
>> Los Angeles, CA 90045
>> http://www.forth.com
>>
>> "Forth-based products and Services for real-time
>> applications since 1973."
>> ==================================================
>
> Hi Elizabeth,
>
> I stand corrected, again ;-)
>
> polyFORTH ISD-4  MSD  Disk 1  Shadows  1988 Mar 14
> ==================================================
> CODE HERE ( - a)   H U) PUSH   NEXT
> CODE PAD ( - a)   H U) 0 MOV   34 # 0 ADD   0 PUSH   NEXT
>
> SwiftX ( 2016 )
> ==============
> TARGET
> : PAD ( -- c-addr )   HERE |NUM| + ;
>
> chipForth ( 1988 )
> ==================
> 2 +USER 'TAB   2 +USER 'PAGE  2 +USER 'MARK   32 + 0 +USER PAD   DROP
>
> So chipForth is the only Forth, Inc. system that puts PAD at the end of the USER variables. Because the chipForth target system is not multi-user.
>
> Since SwiftX provides target versions of QUIT , the targets are multi-user, so  PAD is defined as an offset from  HERE .
>
> Either way, since  H ( used by  HERE )  is a  USER  variable,  PAD  is always in task specific memory.
>
> So the rule is, if you are using a word that uses  PAD  , such as (.) , don't expect PAD to be the same after you call it as before.
>
> But there are no re-entrancy issues, in the sense of  PAD  being used by multiple tasks at the same time, because each task has it's own PAD .
>
> Best regards,
> Howerd
>

I believe the restrictions on "Transient Regions" (3.3.3.6 Other 
transient regions) are pretty clear as to when you can and cannot count 
on the address returned by PAD to be constant.

Basically, it's a temporary buffer of indefinite size (which can be 
quite large) that you can use without having to do a permanent ALLOT, 
and that is often a convenience.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#52582

In article <AJWdndJoT80BELrFnZ2dnUU7-cXNnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 11/12/16 10:35 AM, november.nihal@gmail.com wrote:
>>
>>> Could you enlighten me as to why you think "PAD is a bad idea"?
>>> I am assuming a Forth system where PAD is an array of USER variables...
>>>
>>> Best regards,
>>> Howerd
>>
>> I thought that PAD was the address of a scratch area used for temporary storage!
>
>Correct. According to Forth212, the word PAD returns the address of "a
>transient region that can be used to hold data for intermediate
>processing." In most multi-user systems, each user has one, so there is
>no re-entrancy problem. Most multi-user systems *also* have a "user
>area" where user variables (such as BASE, pointer returned by HERE,
>etc.) reside, but it is not in or near PAD in my experience.

A classical system (say figforth) it reuses the dictionary space between
HERE and the data stack for a fourth purpose (the third purpose being
formatting numbers). It reflects the extreme shortage of memory in
early systems.
Typical space available for desktop systems is now a (couple of) Gbyte.
I can litter my program with
   CREATE file-name 1000 ALLOT
and not run out of space.
With the growth of memory space, the space available to PAD has grown.
I can use it for a temp buffer of a (couple of) Gbyte, so it
may still have its use.

It could probably be dropped from the standard as far as the
language itself is concerned. Making it obsolescent however
doesn't empower implementors in any way, so it makes
little sense and would invalidate a lot of programs.

>
>Cheers,
>Elizabeth
>
>--
>==================================================
>Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>FORTH Inc.                         +1 310.999.6784
>5959 West Century Blvd. Suite 700
>Los Angeles, CA 90045
>http://www.forth.com
>
>"Forth-based products and Services for real-time
>applications since 1973."
>==================================================
-- 
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]

#52612

On Friday, 11 November 2016 11:47:20 UTC, Mark Wills  wrote:
> Forth: You're in control. Everything is global. The system assumes
> you're not an idiot. And I love it.
> 
> Python: You're in control. Everything is global. The system assumes
> you're not an idiot. I hate it.
> 
> And I don't know why!
> 
> Aggggh! :-/

Bizzare which threads get traction and which don't. Didn't take long
for it to descend into bitching.

Has anyone mentioned Hitler yet?

Still not really liking Python. Syntax, like GUIs which requires me to
puzzle-solve is not for me.

I'll stick with it because it's useful, but at the moment it's a 
'through gritted teeth' thing. Maybe I'll warm to it.

Prefer Java ATM if I'm honest. Much faster, and strongly typed.
Reasonably clear syntax (better than C/C++ anyway).

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

#52614

Mark Wills wrote:
> On Friday, 11 November 2016 11:47:20 UTC, Mark Wills  wrote:
> > Forth: You're in control. Everything is global. The system assumes
> > you're not an idiot. And I love it.
> >
> > Python: You're in control. Everything is global. The system assumes
> > you're not an idiot. I hate it.
> >
> > And I don't know why!
> >
> > Aggggh! :-/
>
> Bizzare which threads get traction and which don't. Didn't take long
> for it to descend into bitching.

You were expecting the Spanish Inquisition?  The trajectory of the
thread was set by the subject line and content of the very first post.

> Has anyone mentioned Hitler yet?

You just did.

> Still not really liking Python. Syntax, like GUIs which requires me to
> puzzle-solve is not for me.
>
> I'll stick with it because it's useful, but at the moment it's a
> 'through gritted teeth' thing. Maybe I'll warm to it.
>
> Prefer Java ATM if I'm honest. Much faster, and strongly typed.
> Reasonably clear syntax (better than C/C++ anyway).

Some background as to why you're looking at these would be good
(this is a Forth forum after all).  A question or two even better.

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

#52616

On Monday, 14 November 2016 14:03:28 UTC, HAA  wrote:
> Mark Wills wrote:
> > On Friday, 11 November 2016 11:47:20 UTC, Mark Wills  wrote:
> > > Forth: You're in control. Everything is global. The system assumes
> > > you're not an idiot. And I love it.
> > >
> > > Python: You're in control. Everything is global. The system assumes
> > > you're not an idiot. I hate it.
> > >
> > > And I don't know why!
> > >
> > > Aggggh! :-/
> >
> > Bizzare which threads get traction and which don't. Didn't take long
> > for it to descend into bitching.
> 
> You were expecting the Spanish Inquisition?  The trajectory of the
> thread was set by the subject line and content of the very first post.
> 

So it's my fault? That's harsh, man.

> > Has anyone mentioned Hitler yet?
> 
> You just did.

Nobody else? Wow. Even Hitler would have mentioned Hitler by now.

Oh... wait...

> 
> > Still not really liking Python. Syntax, like GUIs which requires me to
> > puzzle-solve is not for me.
> >
> > I'll stick with it because it's useful, but at the moment it's a
> > 'through gritted teeth' thing. Maybe I'll warm to it.
> >
> > Prefer Java ATM if I'm honest. Much faster, and strongly typed.
> > Reasonably clear syntax (better than C/C++ anyway).
> 
> Some background as to why you're looking at these would be good
> (this is a Forth forum after all).  A question or two even better.

Writing another bloody assembler for a soft CPU. They want it cross
platform. I said "Woohoo! Java then", they said, "Java? Do we look 
like we have long beards? No. We want Python."

When I asked why they wanted Python, since they would be end users
and only interact with the assembler via a command line I got this
response:

"                  "

(i.e. nothing).

Oh well.

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

#52631

On Monday, November 14, 2016 at 10:31:51 AM UTC-5, Mark Wills wrote:
> On Monday, 14 November 2016 14:03:28 UTC, HAA  wrote:
> > Mark Wills wrote:
> > > On Friday, 11 November 2016 11:47:20 UTC, Mark Wills  wrote:
> > > > Forth: You're in control. Everything is global. The system assumes
> > > > you're not an idiot. And I love it.
> > > >
> > > > Python: You're in control. Everything is global. The system assumes
> > > > you're not an idiot. I hate it.
> > > >
> > > > And I don't know why!
> > > >
> > > > Aggggh! :-/
> > >
> > > Bizzare which threads get traction and which don't. Didn't take long
> > > for it to descend into bitching.
> > 
> > You were expecting the Spanish Inquisition?  The trajectory of the
> > thread was set by the subject line and content of the very first post.
> > 
> 
> So it's my fault? That's harsh, man.
> 
> > > Has anyone mentioned Hitler yet?
> > 
> > You just did.
> 
> Nobody else? Wow. Even Hitler would have mentioned Hitler by now.
> 
> Oh... wait...
> 
> > 
> > > Still not really liking Python. Syntax, like GUIs which requires me to
> > > puzzle-solve is not for me.
> > >
> > > I'll stick with it because it's useful, but at the moment it's a
> > > 'through gritted teeth' thing. Maybe I'll warm to it.
> > >
> > > Prefer Java ATM if I'm honest. Much faster, and strongly typed.
> > > Reasonably clear syntax (better than C/C++ anyway).
> > 
> > Some background as to why you're looking at these would be good
> > (this is a Forth forum after all).  A question or two even better.
> 
> Writing another bloody assembler for a soft CPU. They want it cross
> platform. I said "Woohoo! Java then", they said, "Java? Do we look 
> like we have long beards? No. We want Python."
> 
> When I asked why they wanted Python, since they would be end users
> and only interact with the assembler via a command line I got this
> response:
> 
> "                  "
> 
> (i.e. nothing).
> 
> Oh well.

Having only a surface knowledge of Python, what kind of things are p**sing you off about using Python to write an assembler?  Bit twiddling might be kind of "wordy" compared to a Forth solution I suppose, but it supports HEX literals and has logical operators.  

BF

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

#52649

On Monday, 14 November 2016 21:29:16 UTC, foxaudio...@gmail.com  wrote:
> On Monday, November 14, 2016 at 10:31:51 AM UTC-5, Mark Wills wrote:
> > On Monday, 14 November 2016 14:03:28 UTC, HAA  wrote:
> > > Mark Wills wrote:
> > > > On Friday, 11 November 2016 11:47:20 UTC, Mark Wills  wrote:
> > > > > Forth: You're in control. Everything is global. The system assumes
> > > > > you're not an idiot. And I love it.
> > > > >
> > > > > Python: You're in control. Everything is global. The system assumes
> > > > > you're not an idiot. I hate it.
> > > > >
> > > > > And I don't know why!
> > > > >
> > > > > Aggggh! :-/
> > > >
> > > > Bizzare which threads get traction and which don't. Didn't take long
> > > > for it to descend into bitching.
> > > 
> > > You were expecting the Spanish Inquisition?  The trajectory of the
> > > thread was set by the subject line and content of the very first post.
> > > 
> > 
> > So it's my fault? That's harsh, man.
> > 
> > > > Has anyone mentioned Hitler yet?
> > > 
> > > You just did.
> > 
> > Nobody else? Wow. Even Hitler would have mentioned Hitler by now.
> > 
> > Oh... wait...
> > 
> > > 
> > > > Still not really liking Python. Syntax, like GUIs which requires me to
> > > > puzzle-solve is not for me.
> > > >
> > > > I'll stick with it because it's useful, but at the moment it's a
> > > > 'through gritted teeth' thing. Maybe I'll warm to it.
> > > >
> > > > Prefer Java ATM if I'm honest. Much faster, and strongly typed.
> > > > Reasonably clear syntax (better than C/C++ anyway).
> > > 
> > > Some background as to why you're looking at these would be good
> > > (this is a Forth forum after all).  A question or two even better.
> > 
> > Writing another bloody assembler for a soft CPU. They want it cross
> > platform. I said "Woohoo! Java then", they said, "Java? Do we look 
> > like we have long beards? No. We want Python."
> > 
> > When I asked why they wanted Python, since they would be end users
> > and only interact with the assembler via a command line I got this
> > response:
> > 
> > "                  "
> > 
> > (i.e. nothing).
> > 
> > Oh well.
> 
> Having only a surface knowledge of Python, what kind of things are p**sing you off about using Python to write an assembler?  Bit twiddling might be kind of "wordy" compared to a Forth solution I suppose, but it supports HEX literals and has logical operators.  
> 
> BF

It's obtuse class handling syntax. No private methods or even private
instance variables. There's only a *convention* of sticking two
underscores in front of something to mean "this is private".

Yack. Encapsulation doesn't really exist in Python. Everything
is a kind of half-way house.

Class inheritance syntax is tying me up in knots. The cpu instructions
are divided into 8 instruction types, so it makes sense to make classes
for each of those types. Each type knows how to handle/assemble instructions
of its type. In addition, these types will have common methods used to
emit the final assembled op-codes, so a single-instance super class is 
in order there.

Python can do all this stuff no problem, but I think if you've come
from Java the different syntax holds you back. Also defining getter
and setter methods is just weird, requiring "decorators" (Java has
them, too). In fact, you are advised against using them all together.
The Python Zen is to write directly to the instance variables (since
they're all public anyway) and not bother with the overhead of having getters/setters, which is considered Javaesque. My initial reaction to
that is one of horror, but in fairness, it's just a different way of
doing things. We have a notion for not using local variables in Forth,
and using the stack to carry information between functions/words. This
would, I'm sure, induce the same feelings of horror in Python programmers,
at least until they "get it" like we all have as Forth programmers.

And that's it, I guess: I just haven't "got it" yet as far as Python
programming is concerned. When I "got it" in Forth, there was a definite
"Holy crap, I get it, this is AWESOME" moment. That's not happening for
me in Python. It didn't in Java either. I just kind of grew into Java
so it'll probably be the same for Python. It's a neat language. I just
need more time with it, I suppose. And stay away from fancy class
handling techniques ;-)

Reading through various Python materials, the Pythonic way of doing
things is to "make it as simple as possible", and "Don't use classes
unless you really need them". Cool. I'm a Forther, I'm down with that.
I'll just write functions to do it instead. One function for each
instruction type, and common functions for the assembling.

Dunno why I didn't think of that in the first bloody place! I fell into
the "everything is a class" trap. Time to junk the code and start again.

I think the issue is me. I'm thinking in a Javaesque way "everything
is a class", rather than a Pythonic way "Do you *really* need classes?"

I'll probably have it done by tomorrow. Once it's assembling instructions
of one type, it's a matter of cut/paste/mod for the other types.

In the meantime, I need to write some ladder charts for ancient RTUs
(remote telemetry units) to calculate mean pump operation time for
two pumps over a 24 hour period.

SCADA is fun.
I keep telling myself that ;-)

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

#52654

In article <e2c872b0-01f8-4005-9800-21253cfa4748@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>> > Writing another bloody assembler for a soft CPU. They want it cross
>> > platform. I said "Woohoo! Java then", they said, "Java? Do we look=20
>> > like we have long beards? No. We want Python."
>> >=20
>> > When I asked why they wanted Python, since they would be end users
>> > and only interact with the assembler via a command line I got this
>> > response:
>> >=20
>> > "                  "
>> >=20
>> > (i.e. nothing).
>> >=20
>> > Oh well.
>>=20
>> Having only a surface knowledge of Python, what kind of things are p**sin=
>g you off about using Python to write an assembler?  Bit twiddling might be=
> kind of "wordy" compared to a Forth solution I suppose, but it supports HE=
>X literals and has logical operators. =20
>>=20
>> BF
>

>It's obtuse class handling syntax. No private methods or even private
>instance variables. There's only a *convention* of sticking two
>underscores in front of something to mean "this is private".
>
>Yack. Encapsulation doesn't really exist in Python. Everything
>is a kind of half-way house.
>
>Class inheritance syntax is tying me up in knots. The cpu instructions
>are divided into 8 instruction types, so it makes sense to make classes
>for each of those types. Each type knows how to handle/assemble instruction=
>s
>of its type. In addition, these types will have common methods used to
>emit the final assembled op-codes, so a single-instance super class is=20
>in order there.

A more fruitful analysis is to divide assembler commands in 3 groups:
instructions, fixups, and commaer (data).
Look at ciasdis for how this can be iron clad and user friendly,
or the assembler in blocks of ciforth how this works in principle.

http://home.hccnet.nl/a.w.m.van.der.horst/postitfixup.html

(Google gave this as the first hit with
   postit fixup assembler
YMMV, maybe Google just tries to help with vanity searches).

If you're into selling it, this is a perfect example of the
"blackboard" design pattern, much used in ai.

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]

#52663

On Monday, November 14, 2016 at 8:31:51 AM UTC-7, Mark Wills wrote:
> On Monday, 14 November 2016 14:03:28 UTC, HAA  wrote:
> > Some background as to why you're looking at these would be good
> > (this is a Forth forum after all).  A question or two even better.
> 
> Writing another bloody assembler for a soft CPU. They want it cross
> platform. I said "Woohoo! Java then", they said, "Java? Do we look 
> like we have long beards? No. We want Python."
> 
> When I asked why they wanted Python, since they would be end users
> and only interact with the assembler via a command line I got this
> response:
> 
> "                  "
> 
> (i.e. nothing).
> 
> Oh well.

What processor are you assembling to? This isn't the F3C is it?

Anyway, my understanding of Python is that it is a scripting language. You write the actual code in C and then make a Python wrapper around it for the end user to use.

Why don't you just write your assembler in C? That has been done in the past with reasonable success. You can have a Python function called ASM that takes one parameter (the source-file name) and produces an object file.

The reason why I like Forth for assembly is that you get "incremental assembly" --- you can assemble one function at a time and test it immediately --- with a traditional assembler (typically written in C) you can only compile entire source files and produce object files. Development with the assembler is not interactive.

What does your customer want? Do they want an incremental assembler? Most people don't know what this is. Try explaining this on comp.lang.asm.x86 --- I have tried --- nobody understands the concept at all.

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

#52668

On Wednesday, 16 November 2016 02:22:07 UTC, hughag...@gmail.com  wrote:
> On Monday, November 14, 2016 at 8:31:51 AM UTC-7, Mark Wills wrote:
> > On Monday, 14 November 2016 14:03:28 UTC, HAA  wrote:
> > > Some background as to why you're looking at these would be good
> > > (this is a Forth forum after all).  A question or two even better.
> > 
> > Writing another bloody assembler for a soft CPU. They want it cross
> > platform. I said "Woohoo! Java then", they said, "Java? Do we look 
> > like we have long beards? No. We want Python."
> > 
> > When I asked why they wanted Python, since they would be end users
> > and only interact with the assembler via a command line I got this
> > response:
> > 
> > "                  "
> > 
> > (i.e. nothing).
> > 
> > Oh well.
> 
> What processor are you assembling to? This isn't the F3C is it?
> 
> Anyway, my understanding of Python is that it is a scripting language. You write the actual code in C and then make a Python wrapper around it for the end user to use.
> 
> Why don't you just write your assembler in C? That has been done in the past with reasonable success. You can have a Python function called ASM that takes one parameter (the source-file name) and produces an object file.
> 
> The reason why I like Forth for assembly is that you get "incremental assembly" --- you can assemble one function at a time and test it immediately --- with a traditional assembler (typically written in C) you can only compile entire source files and produce object files. Development with the assembler is not interactive.
> 
> What does your customer want? Do they want an incremental assembler? Most people don't know what this is. Try explaining this on comp.lang.asm.x86 --- I have tried --- nobody understands the concept at all.

No, it's not the F3C. This is a virtual CPU - it only exists in software
on an ARM system. They want an assembler for it that can run cross-platform
(Apple, Windows, Linux). They already have the C compiler that spits out
the assembly source (GCC based, apparently) but the assembler they are using
is windows only and they don't have the source code (I know!).

I told them Java gets them cross platform, but they seem to have a dislike
for it. I mean, if you use Python you've still got to install python and
type:

python assembler.py input_file.src

If you use Java then you type:

java assembler.jar input_file.src

I don't really see what the problem is myself, but there you go.
If I had used Java it would be done by now.
For that matter, if I'd used Forth it would be done by now!
Oh well... it's their dime... :-)

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

#52674

On Wednesday, November 16, 2016 at 2:32:05 AM UTC-7, Mark Wills wrote:
> This is a virtual CPU - it only exists in software
> on an ARM system. They want an assembler for it that can run cross-platform
> (Apple, Windows, Linux). They already have the C compiler that spits out
> the assembly source (GCC based, apparently) but the assembler they are using
> is windows only and they don't have the source code (I know!).

Why don't they just use a C compiler such as G that generates ARM assembly-language? ARM assembly-language is the universal assembly-language of the 32-bit micro-controller world?

I have invented my portable assembly-language that is similar to 16-bit x86. The idea is that it can generate machine-code for a variety of 16-bit processors (plus the AVR which is 8-bit), so an assembly-language program will be portable between processors. In some cases (the PIC24) the processor is not used to its full potential because not all hardware-registers are being used. In other cases (the 6812) the processor is used inefficiently because there aren't enough hardware-registers and so some have to be pseudo-registers in memory.

The idea is that a Forth compiler generates this assembly-language. The Forth compiler will work on any target processor, with only the assembler modified to generate machine-code specific to that target processor.

My system is 16-bit --- there are several 16-bit processors in use, plus there are 16-bit FPGA processors --- in the 32-bit world however, everybody just uses the ARM processor, so there is no point in supporting portability between processors.

> I told them Java gets them cross platform, but they seem to have a dislike
> for it. I mean, if you use Python you've still got to install python and
> type:
> 
> python assembler.py input_file.src
> 
> If you use Java then you type:
> 
> java assembler.jar input_file.src
> 
> I don't really see what the problem is myself, but there you go.
> If I had used Java it would be done by now.
> For that matter, if I'd used Forth it would be done by now!
> Oh well... it's their dime... :-)

Actually, all languages are cross-platform in the sense that there are compilers available for all of them. With Java and Python that use a VM you get to port the executable --- with the other languages, you only get to port the source-code, and you have to recompile for each platform --- this makes no difference though, assuming that you have the source-code (this is only an issue in cases in which the programmer didn't release the source-code; but that is not the case here, because you are the programmer and you will give the customer the source-code)

I get the impression that your customers aren't programmers --- they are using the term "cross-platform" and say that this is their goal, but they don't know what the point is --- it is sadly typical for MBAs to use terms and not know what the terms mean.

I'm reminded of Stevie Wonder's song Superstition:
"When you believe in things that you don't understand,
Then you suffer,"

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

#52675

On Wednesday, November 16, 2016 at 2:00:42 PM UTC-7, hughag...@gmail.com wrote:
> Why don't they just use a C compiler such as G that generates ARM assembly-language? ARM assembly-language is the universal assembly-language of the 32-bit micro-controller world?

That was a typo. I meant to say:

Why don't they just use a C compiler such as GCC that generates ARM assembly-language? ARM assembly-language is the universal assembly-language of the 32-bit micro-controller world.

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

#52676

On Wednesday, 16 November 2016 21:00:42 UTC, hughag...@gmail.com  wrote:
> On Wednesday, November 16, 2016 at 2:32:05 AM UTC-7, Mark Wills wrote:
> > This is a virtual CPU - it only exists in software
> > on an ARM system. They want an assembler for it that can run cross-platform
> > (Apple, Windows, Linux). They already have the C compiler that spits out
> > the assembly source (GCC based, apparently) but the assembler they are using
> > is windows only and they don't have the source code (I know!).
> 
> Why don't they just use a C compiler such as G that generates ARM assembly-language? ARM assembly-language is the universal assembly-language of the 32-bit micro-controller world?
> 
> I have invented my portable assembly-language that is similar to 16-bit x86. The idea is that it can generate machine-code for a variety of 16-bit processors (plus the AVR which is 8-bit), so an assembly-language program will be portable between processors. In some cases (the PIC24) the processor is not used to its full potential because not all hardware-registers are being used. In other cases (the 6812) the processor is used inefficiently because there aren't enough hardware-registers and so some have to be pseudo-registers in memory.
> 
> The idea is that a Forth compiler generates this assembly-language. The Forth compiler will work on any target processor, with only the assembler modified to generate machine-code specific to that target processor.
> 
> My system is 16-bit --- there are several 16-bit processors in use, plus there are 16-bit FPGA processors --- in the 32-bit world however, everybody just uses the ARM processor, so there is no point in supporting portability between processors.
> 
> > I told them Java gets them cross platform, but they seem to have a dislike
> > for it. I mean, if you use Python you've still got to install python and
> > type:
> > 
> > python assembler.py input_file.src
> > 
> > If you use Java then you type:
> > 
> > java assembler.jar input_file.src
> > 
> > I don't really see what the problem is myself, but there you go.
> > If I had used Java it would be done by now.
> > For that matter, if I'd used Forth it would be done by now!
> > Oh well... it's their dime... :-)
> 
> Actually, all languages are cross-platform in the sense that there are compilers available for all of them. With Java and Python that use a VM you get to port the executable --- with the other languages, you only get to port the source-code, and you have to recompile for each platform --- this makes no difference though, assuming that you have the source-code (this is only an issue in cases in which the programmer didn't release the source-code; but that is not the case here, because you are the programmer and you will give the customer the source-code)
> 
> I get the impression that your customers aren't programmers --- they are using the term "cross-platform" and say that this is their goal, but they don't know what the point is --- it is sadly typical for MBAs to use terms and not know what the terms mean.
> 
> I'm reminded of Stevie Wonder's song Superstition:
> "When you believe in things that you don't understand,
> Then you suffer,"

They don't want to target the ARM processor specifically. They have a
virtual machine that runs on the native metal. Then their application
(written in C) runs on the virtual CPU. That way they can change their
underlying CPU platform/hardware and all their applications still
work perfectly (as long as they have a virtual machine for it).
The vast majority of PLCs and industrial controllers work like this.
None (that I know) run their application code on the metal. By running
it in a virtual CPU you can instrument it, inspect it, and kill it if
it goes wrong.

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

#52703

On Wednesday, November 16, 2016 at 2:42:43 PM UTC-7, Mark Wills wrote:
> On Wednesday, 16 November 2016 21:00:42 UTC, hughag...@gmail.com  wrote:
> > My system is 16-bit --- there are several 16-bit processors in use, plus there are 16-bit FPGA processors --- in the 32-bit world however, everybody just uses the ARM processor, so there is no point in supporting portability between processors.
>
> They don't want to target the ARM processor specifically. They have a
> virtual machine that runs on the native metal. Then their application
> (written in C) runs on the virtual CPU. That way they can change their
> underlying CPU platform/hardware and all their applications still
> work perfectly (as long as they have a virtual machine for it).
> The vast majority of PLCs and industrial controllers work like this.
> None (that I know) run their application code on the metal. By running
> it in a virtual CPU you can instrument it, inspect it, and kill it if
> it goes wrong.

This is a PLC??? Aren't PLCs always built on 8-bit processors? 

The 8051 has 32 1-bit variables --- afaik, the purpose of this was to support a PLC --- PLCs work primarily with 1-bit flags.

Mitsubishi built a 6502 derivative for a long time that had some extra instructions that allowed it to work with 1-bit flags --- afaik, the purpose of this was to support a PLC.

I have never heard of a 32-bit processor being used for a PLC --- I can't imagine such a thing --- your typical PLC has very little memory (that is why we want 8 flags packed into a single byte, rather than only 1 flag per byte).

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

#52707

> 
> This is a PLC??? Aren't PLCs always built on 8-bit processors? 
> 
> The 8051 has 32 1-bit variables --- afaik, the purpose of this was to support a PLC --- PLCs work primarily with 1-bit flags.
> 
> Mitsubishi built a 6502 derivative for a long time that had some extra instructions that allowed it to work with 1-bit flags --- afaik, the purpose of this was to support a PLC.
> 
> I have never heard of a 32-bit processor being used for a PLC --- I can't imagine such a thing --- your typical PLC has very little memory (that is why we want 8 flags packed into a single byte, rather than only 1 flag per byte).

Telemecanique had their high end PLC's on 386 processors in 199x. In mid 
2000 they had the most basic PLC with M16C controllers. I don't know the
M16C architecture but it's 16bit for sure with some 32bit double register
operations support at least. They claim it 16/32bit whatever that means...

I suspect the newer devices are all 32bit by now.

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

#52741

Most of them are running on ARM now. You'd never know it though. They run a completely virtualised CPU where the CPU underneath is completely abstracted away. This allows the CPU to be changed at any time, but that's not the main reason. It's means the application code is running on a virtual CPU which can be monitored (against it going wrong) quite easily.

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

#52743

On Saturday, November 19, 2016 at 4:01:10 PM UTC-7, Mark Wills wrote:
> Most of them are running on ARM now. You'd never know it though. They run a completely virtualised CPU where the CPU underneath is completely abstracted away. This allows the CPU to be changed at any time, but that's not the main reason. It's means the application code is running on a virtual CPU which can be monitored (against it going wrong) quite easily.

It is possible that we are not talking about the same thing. My understanding of a PLC is that they are programmed with ladder diagrams --- there is no "application code" running on the CPU, virtual or otherwise --- they typically have about 256 bytes of RAM and your ladder diagrams primarily work with 1-bit variables (this is what the 8051 was designed for; it worked well by most accounts).

When I was at Testra, they wanted me to write a PLC for the MiniForth. Nothing came of this. I had never used a PLC, so I wasn't a good candidate for writing one. Also, the job primarily involves GUI programming where the user builds his ladder-diagram by pointing and clicking. I don't know anything about GUI either though. I don't think they were much interested in making a PLC because they don't use PLCs themselves; they just thought that it might boost sales. Tom Hart said that the ladder-diagrams are pretty limited in what they can do, as compared to writing your program in Forth or assembly-language or whatever --- they can be convenient in some circumstances though --- they are useful when you have a factory machine that repeatedly does the same thing; with the ladder-diagram you can make sure that the switches get thrown at the proper time so moving parts don't slam into each other. A lot of factory machines have a carousel that the work-piece rides around on, and at each station something is done to the work-piece, although sometimes they have a conveyer belt --- after our brave little work-piece has made a complete circuit it is ready to drop into the bin of finished work-pieces and get shipped out.

I agree though, that a VM is more secure. This is one of the reasons why my initial version of Straight Forth uses ITC. By replacing the VM with a different version that does debugging, and then recompiling everything, you can monitor what is going on. For example, if some data is getting overwritten, the primitives that write to memory (such as ! etc.) can check where they are writing and halt when they hit the bad place, so you find out where your bug is. In MS-DOS days this was called: "soft ICE."

Debugging like this is all in the future. Right now I'm just working on getting the basic system running. Because it is ITC though, I do have the potential for such debugging later on. 

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

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

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

csiph-web