On Fri, Jan 24, 2020 at 02:23:56PM -0800, ToddAndMargo via perl6-users wrote: > On 2020-01-24 13:49, Peter Pentchev wrote: > > On Fri, Jan 24, 2020 at 09:05:36AM -0800, ToddAndMargo via perl6-users > > wrote: > > > On 2020-01-24 01:17, Marcel Timmerman wrote: > > > > On 1/23/20 6:28 PM, ToddAndMargo via perl6-users wrote: > > > > > > > On Thu, Jan 23, 2020 at 11:51 AM ToddAndMargo via > > > > > > > perl6-users <perl6-us...@perl.org > > > > > > > <mailto:perl6-us...@perl.org>> wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > This is just a trivia question. > > > > > > > > > > > > > > Does anyone know if the actual data stored in > > > > > > > Raku variables is little endian or big endian? > > > > > > > > > > > > > > -T > > > > > > > > > > On 2020-01-23 09:07, Paul Procacci wrote: > > > > > > endianess is dictate by the cpu. > > > > > > If I store the value 4 into some memory address, the storage of > > > > > > and retrieval thereof is controlled by the cpu. > > > > > > > > > > > > > > > > Then I presume Raku rug on a Intel processor would > > > > > be little endian. So when I enter 0xFF44 it is > > > > > really being stored as 44, FF in memory. Interesting. > > > > > > > > Most of the time you don't really need to know unless you move your data > > > > from one machine to another in binary form. In that case you need a test > > > > before interpreting the data. > > > > > > > > Marcel > > > > > > Hi Marcel, > > > > > > The reason for the trivia quest was that I have been > > > doing a lot of stuff with NativeCall lately and > > > you have to prepare data in little endian to > > > send to NativeCall and to interpret bytes of little > > > endian when it come back. So I was just curious. > > > > > > Chuckle. The travails of a high level language: > > > take litle endian apart to put them back together > > > to be restored in what looks like big endian but > > > really is little endian under the hood. > > > > I doubt anything really takes things apart... I'm not sure where you get > > the "what looks like big-endian" from - Marcel's point was that Raku's > > (or Perl's, or Python's, or...) integers and floats do not really look > > like big-endian, they do not look like little-endian, they are > > endian-agnostic. I'd bet that underneath moar and nqp do what is native > > to the platform - so, in x86/amd64's case, Raku is probably > > little-endian all the way, but you don't notice it, because you don't > > need to. > > > > G'luck, > > Peter > > > > > Hi Peter, > > One of the guys over on the WinApi list gave > me a WinAPI call written in assembly. Probably > the one and only time in all the ENTIRE history of > programming where assembly was easier to do > than a high(er) level language. Chuckle!
Ehh, if by "easier" you mean "try to keep track of which registers to
pass the parameters in, where does the first one go, where does the
second one go, oh, there are too many parameters, I have to keep the
rest on the stack... OK, now which registers do I have to save? Nah,
this call promises it will preserve these ones, and I already have that
value in that variable over there, so I don't even need to save this
one... OK, now make the call... now what did it return, a long integer?
Ah, so it's in this register... no, wait, it returned a structure
containing two long integers, so the first one is here and the second
one is over there..."
...okay :)
G'luck,
Peter
PS. Don't get me wrong, I've done a lot of assembly language
programming, and it is undoubtedly the correct tool for some tasks.
Just... not all of them.
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
