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

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

Endianness

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

Contents

  Endianness "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 20:46 +0000
    Re: Endianness Alex <alex@rivadpm.com> - 2017-04-21 22:48 +0100
      Re: Endianness "Elizabeth D. Rather" <erather@forth.com> - 2017-04-21 12:16 -1000
        Re: Endianness "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-22 04:42 +0000
          Re: Endianness "Elizabeth D. Rather" <erather@forth.com> - 2017-04-21 21:45 -1000
    Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-22 11:12 +1000
      Re: Endianness "Elizabeth D. Rather" <erather@forth.com> - 2017-04-21 16:11 -1000
        Re: Endianness hughaguilar96@gmail.com - 2017-04-23 13:41 -0700
        Re: Endianness Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:52 +0000
      Re: Endianness "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-22 04:45 +0000
        Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-23 12:21 +1000
          Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-22 22:49 -0700
            Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-23 18:57 +1000
              Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-23 02:13 -0700
            Re: Endianness "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 03:37 +0000
        Re: Endianness anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-24 16:56 +0000
      Re: Endianness Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-23 04:45 -0500
        Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-24 10:09 +1000
          Re: Endianness "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 14:40 -1000
            Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-24 13:41 +1000
              Re: Endianness "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 17:58 -1000
                Re: Endianness hughaguilar96@gmail.com - 2017-04-23 21:42 -0700
                  Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-23 21:58 -0700
              Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-23 21:18 -0700
                Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-23 21:24 -0700
                Re: Endianness "HAA" <someone@microsoft.com> - 2017-04-26 09:21 +1000
                  Re: Endianness Julian Fondren <julian.fondren@gmail.com> - 2017-04-25 16:56 -0700
    Re: Endianness anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-24 16:58 +0000

Page 1 of 2  [1] 2  Next page →

#57749 — Endianness

I can't really find where it is stated, but I have the impression that
Forth is, more or less, big-endian.

For instance, I have seen code like:

: U.   0 D. ;

This means that, at least for that Forth, the TOS is the high order
cell of a double word. Is this true for all Forth implementations, or
is this just implementation defined?

If this is the case, is this true for bytes in a cell too, or is that
implementation defined?

Is it also true, or implementation defined, that the data stack
generally grows downward?

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I know of no crime that has not been defended by the church,
 in one form or other. The church is not a pioneer; it accepts a
 new truth, last of all, and only when denial has become
 useless."
 -- Robert G. Ingersoll

[toc] | [next] | [standalone]

#57753

On 4/21/2017 21:46, Rudy Velthuis wrote:
> I can't really find where it is stated, but I have the impression that
> Forth is, more or less, big-endian.
> 
> For instance, I have seen code like:
> 
> : U.   0 D. ;
> 
> This means that, at least for that Forth, the TOS is the high order
> cell of a double word. Is this true for all Forth implementations, or
> is this just implementation defined?

True for all.

> 
> If this is the case, is this true for bytes in a cell too, or is that
> implementation defined?

Endianess is to do with byte order. Undefined.

> 
> Is it also true, or implementation defined, that the data stack
> generally grows downward?
> 

Undefined.

-- 
Alex

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

#57754

On 4/21/17 11:48 AM, Alex wrote:
> On 4/21/2017 21:46, Rudy Velthuis wrote:
>> I can't really find where it is stated, but I have the impression that
>> Forth is, more or less, big-endian.
>>
>> For instance, I have seen code like:
>>
>> : U.   0 D. ;
>>
>> This means that, at least for that Forth, the TOS is the high order
>> cell of a double word. Is this true for all Forth implementations, or
>> is this just implementation defined?
>
> True for all.

Per Forth2012 (and Forth94) under Usage Requirements/Cell Pair Types:

3.1.4.1 Double-cell integers
On the stack, the cell containing the most significant part of a 
double-cell integer shall be above the cell containing the least 
significant part.

>> If this is the case, is this true for bytes in a cell too, or is that
>> implementation defined?
>
> Endianess is to do with byte order. Undefined.

Correct. Byte order is unspecified (generally the property of the 
processor).

>> Is it also true, or implementation defined, that the data stack
>> generally grows downward?
>>
>
> Undefined.

Also correct, but downward is the most common implementation. 
Traditionally, the dictionary grows up from low memory and the data 
stack grows down from high memory, and the space in between is 
undefined. The standards do not specify implementation, however.

Cheers,
Elizabeth

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

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

#57772

Elizabeth D. Rather wrote:

> On 4/21/17 11:48 AM, Alex wrote:
> > On 4/21/2017 21:46, Rudy Velthuis wrote:
> > > I can't really find where it is stated, but I have the impression
> > > that Forth is, more or less, big-endian.
> > > 
> > > For instance, I have seen code like:
> > > 
> > > : U.   0 D. ;
> > > 
> > > This means that, at least for that Forth, the TOS is the high
> > > order cell of a double word. Is this true for all Forth
> > > implementations, or is this just implementation defined?
> > 
> > True for all.
> 
> Per Forth2012 (and Forth94) under Usage Requirements/Cell Pair Types:
> 
> 3.1.4.1 Double-cell integers
> On the stack, the cell containing the most significant part of a
> double-cell integer shall be above the cell containing the least
> significant part.
> 
> > > If this is the case, is this true for bytes in a cell too, or is
> > > that implementation defined?
> > 
> > Endianess is to do with byte order. Undefined.
> 
> Correct. Byte order is unspecified (generally the property of the
> processor).
> 
> > > Is it also true, or implementation defined, that the data stack
> > > generally grows downward?
> > > 
> > 
> > Undefined.
> 
> Also correct, but downward is the most common implementation.
> Traditionally, the dictionary grows up from low memory and the data
> stack grows down from high memory, and the space in between is
> undefined. The standards do not specify implementation, however.
> 
> Cheers,
> Elizabeth

Ok, thanks to the both of you. So the higer order cell must be above
the lower oder cell. Good to know or sure, although I already
implemented things that way.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Programming today is a race between software engineers striving
 to build bigger and better idiot-proof programs, and the
 universe trying to build bigger and better idiots. So far, the
 universe is winning."
 -- Rick Cook

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

#57792

On 4/21/17 6:42 PM, Rudy Velthuis wrote:
> Elizabeth D. Rather wrote:
>
>> On 4/21/17 11:48 AM, Alex wrote:
>>> On 4/21/2017 21:46, Rudy Velthuis wrote:
>>>> I can't really find where it is stated, but I have the impression
>>>> that Forth is, more or less, big-endian.
>>>>
>>>> For instance, I have seen code like:
>>>>
>>>> : U.   0 D. ;
>>>>
>>>> This means that, at least for that Forth, the TOS is the high
>>>> order cell of a double word. Is this true for all Forth
>>>> implementations, or is this just implementation defined?
>>>
>>> True for all.
>>
>> Per Forth2012 (and Forth94) under Usage Requirements/Cell Pair Types:
>>
>> 3.1.4.1 Double-cell integers
>> On the stack, the cell containing the most significant part of a
>> double-cell integer shall be above the cell containing the least
>> significant part.
>>
>>>> If this is the case, is this true for bytes in a cell too, or is
>>>> that implementation defined?
>>>
>>> Endianess is to do with byte order. Undefined.
>>
>> Correct. Byte order is unspecified (generally the property of the
>> processor).
>>
>>>> Is it also true, or implementation defined, that the data stack
>>>> generally grows downward?
>>>>
>>>
>>> Undefined.
>>
>> Also correct, but downward is the most common implementation.
>> Traditionally, the dictionary grows up from low memory and the data
>> stack grows down from high memory, and the space in between is
>> undefined. The standards do not specify implementation, however.
>>
>> Cheers,
>> Elizabeth
>
> Ok, thanks to the both of you. So the higer order cell must be above
> the lower oder cell. Good to know or sure, although I already
> implemented things that way.
>

It makes sense, because often you know you have a number that doesn't 
require two cells, and you can simply drop the hi

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

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

#57759

Rudy Velthuis wrote:
> ...
> If this is the case, is this true for bytes in a cell too, or is that
> implementation defined?

This is where things can get messy.  Let's say you need to store a
character in a variable.  Usual practice is to use VARIABLE for this
because there's nothing conveniently smaller.  This leads to use
of @ ! in Forth code to handle characters which is an obvious type
mismatch.  Worse still if you forget and use C@ because then
your code is no longer endian portable.  Ideally Forth would come
with CVARIABLE as standard to encourage use of appropriately
typed operators but it never happened.

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

#57765

On 4/21/17 3:12 PM, HAA wrote:
> Rudy Velthuis wrote:
>> ...
>> If this is the case, is this true for bytes in a cell too, or is that
>> implementation defined?
>
> This is where things can get messy.  Let's say you need to store a
> character in a variable.  Usual practice is to use VARIABLE for this
> because there's nothing conveniently smaller.  This leads to use
> of @ ! in Forth code to handle characters which is an obvious type
> mismatch.  Worse still if you forget and use C@ because then
> your code is no longer endian portable.  Ideally Forth would come
> with CVARIABLE as standard to encourage use of appropriately
> typed operators but it never happened.

Many (if not most) Forths include a CVARIABLE, certainly the ones that 
deal with microcontrollers. There was a strong effort to include 
CVARIABLE in Forth94, but it failed, mostly on the argument that the 
need to save bytes was outdated (I disagreed then and still do). I 
suggest these solutions:

1. If you're using a Forth that has CVARIABLE (or if you want to add 
one) just use it and declare a dependence on it. Here you go:
	: CVARIABLE ( -- ) CREATE 1 ALLOT
               DOES> ( - a ) ;

2. Just use VARIABLE, and do C@ and C! and don't worry about which byte 
the character is in. It will be consistently endian portable on any 
particular device. After all, you never do a C! on one device hoping to 
get that byte with a C@ on a different one.

You won't get in trouble unless you use a mixture of cell-wise and 
byte-wise operators on the same memory location!

Cheers,
Elizabeth

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

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

#57924

On Friday, April 21, 2017 at 7:11:44 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/21/17 3:12 PM, HAA wrote:
> > Ideally Forth would come
> > with CVARIABLE as standard to encourage use of appropriately
> > typed operators but it never happened.
> 
> Many (if not most) Forths include a CVARIABLE, certainly the ones that 
> deal with microcontrollers. There was a strong effort to include 
> CVARIABLE in Forth94, but it failed, mostly on the argument that the 
> need to save bytes was outdated (I disagreed then and still do). I 
> suggest these solutions:

Was this really the kind of thing that the ANS-Forth committee geniuses were debating? This is so trivial as to be meaningless.

> Here you go:
> 	: CVARIABLE ( -- ) CREATE 1 ALLOT
>                DOES> ( - a ) ;

You are so bad at Forth programming that you screwed up even this super-trivial Forth code!

Here you go:

: cvariable create 0 c, ;

The  0 C,  is necessary so the program does the same thing every time if the programmer forgets to store a value in the variable before fetching from it (a common bug). With your code, you are initializing the variable to whatever happened to be in memory. The program may work after some compiles, and may not work after other compiles --- this is difficult bug to track down.

Note that this is the same design flaw that Anton Ertl made in his definition of {: --- he had the locals after the | being initialized to an unknown value --- the correct way to do this (what I did in the novice-package) is initialize them to zero.

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

#58796

Am Fri, 21 Apr 2017 16:11:37 -1000 schrieb Elizabeth D. Rather:
> There was a strong effort to include CVARIABLE in Forth94, but it
> failed, mostly on the argument that the need to save bytes was outdated
> (I disagreed then and still do). I suggest these solutions:

In a hosted system, the alignment restrictions for headers make it 
difficult to save any space with CVARIABLE.  Neither Gforth nor VFX has 
CVARIABLE, and I'm surprised that SwiftForth hasn't, either.

Only on embedded systems with headers in ROM (or on the development 
system) and the variable space in the precious tiny RAM you really 
benefit from CVARIABLE.

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

#57773

HAA wrote:

> Rudy Velthuis wrote:
> > ...
> > If this is the case, is this true for bytes in a cell too, or is
> > that implementation defined?
> 
> This is where things can get messy.  Let's say you need to store a
> character in a variable.  Usual practice is to use VARIABLE for this
> because there's nothing conveniently smaller.  This leads to use
> of @ ! in Forth code to handle characters which is an obvious type
> mismatch.  Worse still if you forget and use C@ because then
> your code is no longer endian portable.

I'd say it is, because C@ (and C!) deal with (how do they call them?
address units?) bytes, and in every language I know, no matter if it is
on a big- or little-endian platform, bytes are always stored at
consecutive addresses. It only gets hairy if you store a byte with ! or
fetch it with @. But you shouldn't do that anyway, in no language I
know.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Nothing exists except atoms and empty space; everything else
 is opinion."
 -- Democritus

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

#57876

Rudy Velthuis wrote:
> HAA wrote:
>
> > Rudy Velthuis wrote:
> > > ...
> > > If this is the case, is this true for bytes in a cell too, or is
> > > that implementation defined?
> >
> > This is where things can get messy.  Let's say you need to store a
> > character in a variable.  Usual practice is to use VARIABLE for this
> > because there's nothing conveniently smaller.  This leads to use
> > of @ ! in Forth code to handle characters which is an obvious type
> > mismatch.  Worse still if you forget and use C@ because then
> > your code is no longer endian portable.
>
> I'd say it is, because C@ (and C!) deal with (how do they call them?
> address units?) bytes, and in every language I know, no matter if it is
> on a big- or little-endian platform, bytes are always stored at
> consecutive addresses. It only gets hairy if you store a byte with ! or
> fetch it with @. But you shouldn't do that anyway, in no language I
> know.

As far as Forth is concerned a character/byte on the stack *is* an
integer and using ! to store is quite legal assuming destination has
at least 1 cell of space.

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

#57888

On Saturday, April 22, 2017 at 9:22:04 PM UTC-5, HAA wrote:
> Rudy Velthuis wrote:
> > HAA wrote:
> >
> > > Rudy Velthuis wrote:
> > > > ...
> > > > If this is the case, is this true for bytes in a cell too, or is
> > > > that implementation defined?
> > >
> > > This is where things can get messy.  Let's say you need to store a
> > > character in a variable.  Usual practice is to use VARIABLE for this
> > > because there's nothing conveniently smaller.  This leads to use
> > > of @ ! in Forth code to handle characters which is an obvious type
> > > mismatch.  Worse still if you forget and use C@ because then
> > > your code is no longer endian portable.
> >
> > I'd say it is, because C@ (and C!) deal with (how do they call them?
> > address units?) bytes, and in every language I know, no matter if it is
> > on a big- or little-endian platform, bytes are always stored at
> > consecutive addresses. It only gets hairy if you store a byte with ! or
> > fetch it with @. But you shouldn't do that anyway, in no language I
> > know.
> 
> As far as Forth is concerned a character/byte on the stack *is* an
> integer and using ! to store is quite legal assuming destination has
> at least 1 cell of space.

Why are you saying this like it's novel, or like it refutes what it
replies to? Fetching a cell from an address containing only a char is
(probably) a type error. In Forth, you manage your types yourself.
Your errors are still errors. "You shouldn't index out of array
bounds, in no language I know." also isn't rebutted by "Forth doesn't
check for that". If you have an off-by-one error in an loop pover
array contents you can still go on to display garbage to the user,
etc.

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

#57892

Julian Fondren wrote:
> On Saturday, April 22, 2017 at 9:22:04 PM UTC-5, HAA wrote:
> > Rudy Velthuis wrote:
> > > HAA wrote:
> > >
> > > > Rudy Velthuis wrote:
> > > > > ...
> > > > > If this is the case, is this true for bytes in a cell too, or is
> > > > > that implementation defined?
> > > >
> > > > This is where things can get messy.  Let's say you need to store a
> > > > character in a variable.  Usual practice is to use VARIABLE for this
> > > > because there's nothing conveniently smaller.  This leads to use
> > > > of @ ! in Forth code to handle characters which is an obvious type
> > > > mismatch.  Worse still if you forget and use C@ because then
> > > > your code is no longer endian portable.
> > >
> > > I'd say it is, because C@ (and C!) deal with (how do they call them?
> > > address units?) bytes, and in every language I know, no matter if it is
> > > on a big- or little-endian platform, bytes are always stored at
> > > consecutive addresses. It only gets hairy if you store a byte with ! or
> > > fetch it with @. But you shouldn't do that anyway, in no language I
> > > know.
> >
> > As far as Forth is concerned a character/byte on the stack *is* an
> > integer and using ! to store is quite legal assuming destination has
> > at least 1 cell of space.
>
> Why are you saying this like it's novel, or like it refutes what it
> replies to? Fetching a cell from an address containing only a char is
> (probably) a type error. In Forth, you manage your types yourself.
> Your errors are still errors. "You shouldn't index out of array
> bounds, in no language I know." also isn't rebutted by "Forth doesn't
> check for that". If you have an off-by-one error in an loop pover
> array contents you can still go on to display garbage to the user,
> etc.

This is what was said:

> > Rudy Velthuis wrote:
> > > ...
> > > It only gets hairy if you store a byte with ! or
> > > fetch it with @. But you shouldn't do that anyway, in no language I
> > > know.

And I was refuting it - politely.

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

#57893

On Sunday, April 23, 2017 at 3:58:41 AM UTC-5, HAA wrote:
> This is what was said:
> 
> > > Rudy Velthuis wrote:
> > > > ...
> > > > It only gets hairy if you store a byte with ! or
> > > > fetch it with @. But you shouldn't do that anyway, in no language I
> > > > know.
> 
> And I was refuting it - politely.

OK. Then this is what I have to say about that:

> > Fetching a cell from an address containing only a char is
> > (probably) a type error. In Forth, you manage your types yourself.
> > Your errors are still errors. "You shouldn't index out of array
> > bounds, in no language I know." also isn't rebutted by "Forth doesn't
> > check for that". If you have an off-by-one error in an loop [over]
> > array contents you can still go on to display garbage to the user,
> > etc.

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

#58332

Julian Fondren wrote:

> On Saturday, April 22, 2017 at 9:22:04 PM UTC-5, HAA wrote:
> > Rudy Velthuis wrote:
> > > HAA wrote:
> > > 
> > > > Rudy Velthuis wrote:
> > > > > ...
> > > > > If this is the case, is this true for bytes in a cell too, or
> > > > > is that implementation defined?
> > > > 
> > > > This is where things can get messy.  Let's say you need to
> > > > store a character in a variable.  Usual practice is to use
> > > > VARIABLE for this because there's nothing conveniently smaller.
> > > > This leads to use of @ ! in Forth code to handle characters
> > > > which is an obvious type mismatch.  Worse still if you forget
> > > > and use C@ because then your code is no longer endian portable.
> > > 
> > > I'd say it is, because C@ (and C!) deal with (how do they call
> > > them?  address units?) bytes, and in every language I know, no
> > > matter if it is on a big- or little-endian platform, bytes are
> > > always stored at consecutive addresses. It only gets hairy if you
> > > store a byte with ! or fetch it with @. But you shouldn't do that
> > > anyway, in no language I know.
> > 
> > As far as Forth is concerned a character/byte on the stack is an
> > integer and using ! to store is quite legal assuming destination has
> > at least 1 cell of space.
> 
> Why are you saying this like it's novel, or like it refutes what it
> replies to? Fetching a cell from an address containing only a char is
> (probably) a type error.

That is what I meant. 

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Properly read, the Bible is the most potent force for atheism
 ever conceived." -- Isaac Asimov"

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

#58006

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>I'd say it is, because C@ (and C!) deal with (how do they call them?
>address units?) bytes,

They deal with chars.  But "bytes" is good enough for a
general discussion.

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

#57895

HAA <someone@microsoft.com> wrote:
> Rudy Velthuis wrote:
>> ...
>> If this is the case, is this true for bytes in a cell too, or is that
>> implementation defined?
> 
> This is where things can get messy.  Let's say you need to store a
> character in a variable.  Usual practice is to use VARIABLE for this
> because there's nothing conveniently smaller.  This leads to use
> of @ ! in Forth code to handle characters which is an obvious type
> mismatch.

This doesn't really make any sense to me.  You can always access
individual bytes of storage, so creating a VARIABLE and accessing it
with C@ and C! is just fine.

> Worse still if you forget and use C@ because then your code is no
> longer endian portable.  Ideally Forth would come with CVARIABLE as
> standard to encourage use of appropriately typed operators but it
> never happened.

I guess you'd save a tiny amount of storage, which might be relevant
on a tiny machine.  To get any benefit you might have to allocate
CVARIABLEs in a block, because cell-sized variables might have to be
aligned, as might dictionary headers.

Andrew.

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

#57932

Andrew Haley wrote:
> HAA <someone@microsoft.com> wrote:
> > Rudy Velthuis wrote:
> >> ...
> >> If this is the case, is this true for bytes in a cell too, or is that
> >> implementation defined?
> >
> > This is where things can get messy.  Let's say you need to store a
> > character in a variable.  Usual practice is to use VARIABLE for this
> > because there's nothing conveniently smaller.  This leads to use
> > of @ ! in Forth code to handle characters which is an obvious type
> > mismatch.
>
> This doesn't really make any sense to me.  You can always access
> individual bytes of storage, so creating a VARIABLE and accessing it
> with C@ and C! is just fine.

It is fine.  But when a programmer unfamiliar with the code notes
storage labelled VARIABLE, he may well conclude @ and ! was
appropriate and mistakenly apply it.  Endianness may bring forth
the error, or hide it.  Finding the bug could prove interesting.

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

#57936

On 4/23/17 2:09 PM, HAA wrote:
> Andrew Haley wrote:
>> HAA <someone@microsoft.com> wrote:
>>> Rudy Velthuis wrote:
>>>> ...
>>>> If this is the case, is this true for bytes in a cell too, or is that
>>>> implementation defined?
>>>
>>> This is where things can get messy.  Let's say you need to store a
>>> character in a variable.  Usual practice is to use VARIABLE for this
>>> because there's nothing conveniently smaller.  This leads to use
>>> of @ ! in Forth code to handle characters which is an obvious type
>>> mismatch.
>>
>> This doesn't really make any sense to me.  You can always access
>> individual bytes of storage, so creating a VARIABLE and accessing it
>> with C@ and C! is just fine.
>
> It is fine.  But when a programmer unfamiliar with the code notes
> storage labelled VARIABLE, he may well conclude @ and ! was
> appropriate and mistakenly apply it.  Endianness may bring forth
> the error, or hide it.  Finding the bug could prove interesting.

So long as you consistently use *either* c@/c! *or* @/! you're fine. You 
only get in trouble if you've done a ! and then do a c@ and wonder what 
you've got.

Cheers,
Elizabeth

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

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

#57949

Elizabeth D. Rather wrote:
> On 4/23/17 2:09 PM, HAA wrote:
> > Andrew Haley wrote:
> >> HAA <someone@microsoft.com> wrote:
> >>> Rudy Velthuis wrote:
> >>>> ...
> >>>> If this is the case, is this true for bytes in a cell too, or is that
> >>>> implementation defined?
> >>>
> >>> This is where things can get messy.  Let's say you need to store a
> >>> character in a variable.  Usual practice is to use VARIABLE for this
> >>> because there's nothing conveniently smaller.  This leads to use
> >>> of @ ! in Forth code to handle characters which is an obvious type
> >>> mismatch.
> >>
> >> This doesn't really make any sense to me.  You can always access
> >> individual bytes of storage, so creating a VARIABLE and accessing it
> >> with C@ and C! is just fine.
> >
> > It is fine.  But when a programmer unfamiliar with the code notes
> > storage labelled VARIABLE, he may well conclude @ and ! was
> > appropriate and mistakenly apply it.  Endianness may bring forth
> > the error, or hide it.  Finding the bug could prove interesting.
>
> So long as you consistently use *either* c@/c! *or* @/! you're fine. You
> only get in trouble if you've done a ! and then do a c@ and wonder what
> you've got.
>
> Cheers,
> Elizabeth

Too many assumptions.  You use C@ C! on a VARIABLE.  I come along
later to do a mod and see VARIABLE.  I naturally assume @ ! is required.
Everything still works.  Nobody knows there is now a ticking time bomb
in the code.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web