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