[NoW] A question about mixed-endianness

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[NoW] A question about mixed-endianness

Egor Skriptunoff-2
Hi!
It's Wednesday again. 
It's time for nitpicking  :-)
 
1)  Funny name
 
The name of the symbol MYINT in "lundump.h" looks strange.
   #define MYINT(s)    (s[0]-'0')
Probably, something like DIGIT2INT would be a more appropriate name?
 
 
 
2)  A small step towards cross-platform compatibility of Lua bytecode
 
It seems that Lua 5.4 (Lua@Github Jan 30 2019) bytecode
doesn't depend on platform word size and pointer size anymore
due to another implementation of LoadStringN() and LoadInt().
So, why bytecode header contains sizeof(int) and sizeof(size_t) ?
Why Lua refuses to load bytecode if these values don't correspond
to the current platform?
 
Yes, there might be a hypothetical risk of loading, for example,
very long function prototype (100K instructions)
on a platform having 16-bit C int.
IMO, the preferred workaround would be to remove sizeof(int) and sizeof(size_t)
from bytecode header and insert additional check inside LoadSize():
before calculating (x<<7), make sure x is not greater than (MAX_INT>>7).
This way Lua bytecodes for Android, x86 and x64 platforms would be identical.
 
But I don't know why do we need cross-platform compatibility of Lua bytecode? :-)
 
 
 
3)  Mixed-endianness
 
"Mixed-endian" means that endianness is neither little-endian nor big-endian.
According to Wikipedia, such CPUs do exist.
I'm trying to determine whether Lua 5.3 support mixed-endian platforms or not?
 
My first guess was "yes", because of bytecode header layout:
Lua 5.2 has "LE/BE" boolean field in bytecode file header.
Lua 5.3 doesn't have this boolean field. Instead, two new fields were added,
these fields contain dumped numeric constants (0x5678 and 370.5).
This might mean that mixed-endian platforms are supported since Lua 5.3
(otherwise why boolean flag "LE/BE" was replaced with dumped integer value?).
 
My second guess was "no", because of string.pack() and string.unpack()
rely on assumption that native endianness is either LE or BE.
I don't have a mixed-endian device to test, but I guess that these functions
would work incorrectly on mixed-endian platforms.
 
Lua is claimed to be extremely portable, hence the questions:
  Does Lua support mixed-endian platforms?
  Should Lua support them?

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] A question about mixed-endianness

Coda Highland
On Wed, Mar 13, 2019 at 5:03 PM Egor Skriptunoff <[hidden email]> wrote:
Lua is claimed to be extremely portable, hence the questions:
  Does Lua support mixed-endian platforms?

I suspect that pack and unpack are the only things that would break, and those might not even fail too obscenely as long as you didn't try to migrate the data across architectures. The C compiler ought to abstract away the rest. If you REALLY wanted to sidestep that, then you could use hton*() and ntoh*() and trust that the C library knows how to deal with it.
 
  Should Lua support them?

Probably not. Mixed-endian systems went the way of the dinosaur long ago. VAX and the PDP series are the only architectures I can find that were mixed-endian and also had any meaningful amount of penetration, and basically nobody uses those outside of retrocomputing enthusiasts anymore. I don't think the target audience would be worth putting ANY effort into it.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: [NoW] A question about mixed-endianness

Sean Conner
It was thus said that the Great Coda Highland once stated:
> On Wed, Mar 13, 2019 at 5:03 PM Egor Skriptunoff <[hidden email]>
> wrote:
>
> >   Should Lua support them?
> >
>
> Probably not. Mixed-endian systems went the way of the dinosaur long ago.
> VAX and the PDP series are the only architectures I can find that were

  The VAX was (is?) little endian (integers and pointers), but the floating
point is *NOT* IEEE-754 and in fact, does appear to be mixed-endian in
nature, to remain compatible with the PDP-11.

> mixed-endian and also had any meaningful amount of penetration, and
> basically nobody uses those outside of retrocomputing enthusiasts anymore.
> I don't think the target audience would be worth putting ANY effort into it.

  Agree.

  -spc (Who in nearly 35 years of computer experience has yet to come across
        a sign-magnitude or 1s-complement machine ... )

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] A question about mixed-endianness

Dirk Laurie-2
Op Do. 14 Mrt. 2019 om 03:57 het Sean Conner <[hidden email]> geskryf:

>   -spc (Who in nearly 35 years of computer experience has yet to come across
>         a sign-magnitude or 1s-complement machine ... )

My very first experience of assembly language (admittedly more than 35
years ago) was on the IBM 1620. That's a sign-magnitude machine.

It's also a BCD machine with individually addressable digits and
arbitrary length decimal arithmetic, which however it can't do unless
you load addition and multiplication tables. All these features are
also probably not found on a machine only 35 years old.

-- Dirk

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] A question about mixed-endianness

Roberto Ierusalimschy
In reply to this post by Egor Skriptunoff-2
> It's Wednesday again.
> It's time for nitpicking  :-)

Again, thanks for the suggestions.


> 3)  Mixed-endianness
>
> "Mixed-endian" means that endianness is neither little-endian nor
> big-endian.
> According to Wikipedia, such CPUs do exist.
> I'm trying to determine whether Lua 5.3 support mixed-endian platforms or
> not?
>
> [...]
>
> My second guess was "no", because of *string.pack()* and *string.unpack()*
> [...]

It seems a little harsh to say that Lua does not support mixed-endian
platforms just because of these two functions (that still work Ok for
non-native endianness). We added a note in the manual explaining that
"native mode" assumes either little or big-endian, and therefore may
not work correctly on mixed-endian formats.

-- Roberto