Re: LSE64 in standard Forth

Bernd Paysan wrote:
John Doty wrote:
Consider "+". In LSE64, "+" is specified to add a pair of 64 bit twos
complement integers. But in Standard Forth, who knows?

You use C's "+" operator, which is "who knows" as well. I haven't seen one's
complement machines for ages, so it's simply the same thing as with C: + is
two's complement unless you are on a really exotic piece of hardware.

Yes, so in principle it's "who knows", but in practice it's well defined. But in Standard Forth it's not well defined, not because of the two's complement issue, but because of the size.


So, an implementation of Standard Forth in LSE64 is relatively trivial, since
LSE64's spec here (and in many other places) is allowable by the
standard. But the standard doesn't give you that kind of firm foundation
to stand on going the other way.

Neither does the C standard, but in real life, most C programs depend on 8
bit chars, two's complement numbers, weak aliasing and so on (all of that
not guaranteed by the C standard).

I'm only interested in what works in real life.

Lots of them depend even on 32 bit ints,
and 64 bit long longs, IEEE single and double, and often even on a
particular endianess (mostly little endian).

Shakier. The worst is maybe assuming that you can cast a pointer to an int. Of course, you can avoid such problems without much trouble, and I believe I have for most practical purposes in LSE64.

The same is true for ANS Forth
programs. And there's even a word for it, it's called environmental
dependency, and all you need to do if you claim ANS Forth compatibility is
to document the actual dependencies.

And as Mr. J pointed out, hardly anyone does this.


What you do here is language lawyering. The problem with standards is that
there needs to be some consense, and often somebody steps in and says "My
exotic hardware can't implement Forth in a standard way if xyz". Well, ok,
the compromise is that xyz is not a required condition, but most people
still take xyz for granted, and the exotic hardware gives you a headache
when porting to.

I'm not a language lawyer, I'm more a language anarchist ;-)

Don't standardize, implement (portably). What you need is a practical "machine-independent assembler" as a foundation.


Jeff Fox ranted on ANS Forth some time ago when he still worked for iTV, and
one of his rants were that some contractor wrote a piece of software, which
assumed 32 bit integers, 8 bit chars, and probably also a particular
endianess, and it certainly didn't run on the i21. That's not the fault of
ANS Forth, but of the programmer, and Jeff Fox rant was more about the
quality of so-called "ANS Forth" coders than about ANS Forth itself.

Fact is: People do take assumptions about common hardware, and code for
common hardware, regardless if that's C or Forth.

Yes, but C has better mechanisms to cope here. Not perfect, but better. That's why it is the common "machine-independent assembler". A carefully crafted Forth dialect might be able serve as well, but there's no example I know of that fits this role.

If you want your hardware
to become popular, sticking to common word widths and memory layouts (byte
addressed, big or little endian) is a good idea, unless you have
sufficiently good explanations why you don't.

C shows the influence of the IBM 360 in its design (even if the first implementation was on a different machine). The 360 was very influential in both hardware and software (things like INTEGER*4 declarations on Fortran). Three of the four C implementations listed in K&R edition 1 are 8/16/32 bit machines. Of course, this produced positive feedback both on the languages and the machines.

On the other hand, most Forths still show their IBM 1130 ancestry, particularly in the single/double/mixed integer arithmetic model. While for many in my generation the 1130 was the computer we learned programming on, it was not so influential on computer architecture as the 360.

--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • Re: code portability
    ... And I'm sure there are 1s complement ... machines, or otherwise where these weaknesses are truly manifest. ... *defacto* standard supports them. ...
    (comp.lang.c)
  • Re: CHAR_BIT < 8?
    ... merely that they are not the definition in the C standard. ... same way the hardware has no concept of the C standard. ... conforming C implementation. ... Presumably santosh was not referring to all possible machines, ...
    (comp.lang.c)
  • Re: LSE64 in standard Forth
    ... But in Standard Forth, who knows? ... complement machines for ages, so it's simply the same thing as with C: ... two's complement unless you are on a really exotic piece of hardware. ... The same is true for ANS Forth ...
    (comp.lang.forth)
  • Re: reporting default integer size
    ... You can assume twos complement integers, ... Fortran was very popular on those machines. ... You might assume IEEE binary floating point, ... If you know the hardware you will be running on, ...
    (comp.lang.fortran)
  • Re: signed int overflow
    ... >>overflow is defined as if twos complement arithmetic was being performed. ... > That would be expensive on hardware that doesn't use 2's complement. ... by a standard the enforces 2's complement and defined overflow behaviour. ...
    (comp.lang.cpp)