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

#57950

On 4/23/17 5:41 PM, HAA wrote:
> 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.

 From a team POV, you're absolutely right. I was coming from a purely 
technical POV.

In today's world, it's necessary to have C@ and C! for writing to 8-bit 
ports or putting a character into a string. Maybe CVARIABLE is useful 
for notifying someone reading the code about the nature of the item, but 
except in seriously resource-constrained microcontrollers it won't save 
space, which I assume is the rationale for dropping it. I can still 
remember the fight in the early 90's over declaring BASE to be a cell wide!

Cheers,
Elizabeth

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

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

#57956

On Sunday, April 23, 2017 at 8:58:53 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/23/17 5:41 PM, HAA wrote:
> > Elizabeth D. Rather wrote:
> >> 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.
> >
> > 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.
> 
>  From a team POV, you're absolutely right. I was coming from a purely 
> technical POV.

You're coming from a "purely technical POV"??? LOL

> In today's world, it's necessary to have C@ and C! for writing to 8-bit 
> ports or putting a character into a string. 

Actually, in "today's word" micro-controllers don't have 8-bit ports. The MiniForth that came out in 1994/1995 didn't have 8-bit ports --- IIRC, it didn't have C@ and C! either (I may have written them using some logic to only access the lower byte; I don't remember).

Also, in Straight Forth it won't be necessary to have C@ and C! for accessing characters in strings. You give a quotation to a HOF and the HOF calls the quotation for every char, giving the char to the quotation as a parameter. So, you don't need C@. You don't need C! either because you don't write into existing strings --- you build a new string.

I will get rid of C@ and C! altogether. As HAA points out, it is error-prone. I will just have cells but not have chars. 

I may have 8-bit chars in strings, but that is an internal representation that won't be exposed to the user --- the user doesn't know if the strings are of 8-bit or 32-bit or 64-bit elements --- different implementations of Straight Forth may have different representations of strings internally (ASCII, Extended-ASCII, UTF-8, UTF-16, UTF-32, etc.).

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

#57958

On Sunday, April 23, 2017 at 11:42:19 PM UTC-5, hughag...@gmail.com wrote:
> I may have 8-bit chars in strings, but that is an internal representation that won't be exposed to the user --- the user doesn't know

How incredibly Forth-ish.

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

#57953

On Sunday, April 23, 2017 at 10:41:58 PM UTC-5, HAA wrote:
> 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.

Q. golly gosh, how could such a bomb be avoided?

A1.

  CREATE var 0 c,

A2.

  1 BUFFER: var

A3.

  class stuff
    cvariable a
    cvariable b \ actually one byte away from a
    cvariable c
  end-class

A4.

  VARIABLE var  \ only accessed with C@ and C!

A5. 

  VARIABLE var
  : reset ( -- )  0 var c! ;
  : incr ( -- )  1 var +! ;
  : odd? ( -- f )  var c@ 1 and ;

  ( never again refer to var )

A6.

  PACKAGE variables-what-not-to-be-touched

  PRIVATE

  VARIABLE var

  PUBLIC

  : reset ... ;
  ...

  END-PACKAGE

A7.

  int main() {
    char var;
    ...
  }

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

#57955

On Sunday, April 23, 2017 at 11:18:24 PM UTC-5, Julian Fondren wrote:
>   VARIABLE var
>   : reset ( -- )  0 var c! ;
>   : incr ( -- )  1 var +! ;

I meant to do that.

This code has an environmental dependency on little-endianness.

The application involves incrementing a bunch of bits until they
finally disturb the 8 bits accessed by ODD?

It's a niche app. You probably haven't heard of it.

>   : odd? ( -- f )  var c@ 1 and ;
> 
>   ( never again refer to var )

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

#58160

Julian Fondren wrote:
> On Sunday, April 23, 2017 at 10:41:58 PM UTC-5, HAA wrote:
> > 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.
>
> Q. golly gosh, how could such a bomb be avoided?
>
> A1.
>
> A2.
>
> A3.
>
> A4.

> A5.
>
> A6.
>
> A7.
>

So you admit there's an issue resulting from a variety of responses.  Good.

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

#58164

On Tuesday, April 25, 2017 at 6:21:58 PM UTC-5, HAA wrote:
> So you admit there's an issue resulting from a variety of responses.  Good.

Ah, yes.

I didn't want to admit this, but you've cleverly sussed it out.

Well, I'll go on and state it clearly then.

Mother, please forgive me:

IT IS POSSIBLE

TO HAVE BUGS

IN SOFTWARE

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

#58007

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>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?

It is true of standard implementations.

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

Implementation defined.

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

Implementation defined.

Also of relevance: 2! ( x1 x2 a-addr -- ) stores x2 at a-addr and x1
at the next cell, so if you use it to store a double, you have stored
the double in big-endian order indeed; 2@ reads the items in the
corresponding order.

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

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

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

csiph-web