home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 116,371 of 117,927   
   Krishna Myneni to dxf   
   Re: DLSHIFT and DRSHIFT   
   28 Mar 24 08:38:07   
   
   From: krishna.myneni@ccreweb.org   
      
   On 3/28/24 06:29, dxf wrote:   
   > On 28/03/2024 2:44 am, Krishna Myneni wrote:   
   >> On 3/27/24 08:57, dxf wrote:   
   >>> On 27/03/2024 10:26 pm, Ruvim wrote:   
   >>>> On 2024-03-27 04:57, Krishna Myneni wrote:   
   >>>> [...]   
   >>>>> We shouldn't have an ambiguous condition here because of some   
   idiosyncratic behavior of the SHL instruction!   
   >>>>>   
   >>>>> u 64 LSHIFT should be zero on all systems with cell sizes up to 64 bits.   
   >>>>   
   >>>> Ideally — yes.   
   >>>>   
   >>>> My rationale (see [1]) is that for any `x` and `u`, the result of a   
   single shift of `x` by `u` bits should always be equivalent to `u` sequential   
   shifts by 1 bit.   
   >>>>   
   >>>> But neither the standard nor implementations follow this idea.   
   >>>   
   >>> The same occurred with 2/ and 2 / .  Those who saw Forth as a language   
   wanted   
   >>> consistent results; whereas those who saw Forth as a toolkit said give us   
   what   
   >>> the hardware provides.   
   >>>   
   >>   
   >> If one needs the machine shift instructions, they should be using the Forth   
   assembler to write the word in which it is needed. The language specification   
   has no justification (that I can see) for undefined behavior for the LSHIFT   
   and RSHIFT    
   instructions.   
   >   
   > Some 40 years ago Intel told their customers there's no justification for   
   shifting   
   > a full cell of bits.  ANS told the same thing to forthers.   
   >   
   >   
      
   This really isn't an issue with the processor design -- they're under   
   more severe constraints in what they can put in the hardware. The   
   desired behavior can be achieved in software.   
      
   When I first started programming in Forth, I appreciated the fact that   
   it was close to the hardware. As processor speed and memory size and the   
   complexity of my programs grew, and the need to share them as well, the   
   cleanliness and portability of the language became more important.   
      
   --   
   Krishna   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca