218700+ entries in 0.134s
mircea_popescu: rust is pretty much
the anti-language ; as someone explained "the red hat decided
to present it as
the
thing and hope for all
the idiots
to contribute freely
to make it
the
thing for
this reason".
mircea_popescu: i couldn't care less what rust dork has
to say on any
topic.
mircea_popescu: you understand, all
this, cpu freq, bus aperture, words etc exist because simple and cheap solution
to
the clock problem
mircea_popescu: the only way
to make
them wrong would be
to make your cpu work without clock and bus cycles.
mircea_popescu: and someone somewhere is going
to want
to
talk of it directly rather
than haskelly, and so
they will use
the concept of... machine words.
mircea_popescu: myeah. but if i ever make a chip myself,
there's not going
to be fucking carry speshul bit.
mircea_popescu: ie, origin ally
the philosophical minds prevailed, and a special wire was added (the carry). but
then ww2 ended and saner minds prevailed ;
thus double sized results on
the same bus and
the world went back
to
the peace and prosperity of everything in band.
mircea_popescu: incidentally
this whole
thing with mul add etc is a fine working example for
the in band / out of band discussion.
mircea_popescu: well yes, but as long as
the job is "check for machine word fixed
type",
the carry will save you.
mircea_popescu: asciilifeform
there's also fleshlights. i don't program on
those.
mircea_popescu: yes but here is used conceptually, as
the "top half of
the result", be it 1 bit or 1 machine word.
mircea_popescu: ok. what's
this
to do with ada i dunno, but anyway,
there it is.
mircea_popescu: so it just returns
the same as 0x000000000 + 0x000000000 ?
mircea_popescu: so you do 0x100000000 * 0x100000000 and get
the carry set and you blew it.
mircea_popescu: i didn't realise
the above high level math was stand-in for asm.
mircea_popescu: you get memory access violation for
trying
to write at offset-1 in memory.
mircea_popescu: it's not clear how you represent
the y ; but whatever, half questions ftw.
mircea_popescu: the
test MAY NOT BE > 0 (or -1 ?) and < 0x10000000000000000. if
the compiler does
that
the compiler is very, very stupid.
mircea_popescu: the range is 0
to 0xfffffffffffffff.
the
test is >= 0 and <= 0xfffffffffffffff.
mircea_popescu: if
the compile rules do "add one and <"
the compiler is wrong ; it should not add one ad <=.
mircea_popescu: indeed 0x10000000000000000 is not what
the program stated ; and indeed
the problem is
that (if)
the compiler adds one
to what
the program statyed ; it shouldn't do
that.
mircea_popescu: i
thought bounds checking was introduced by
the compiler not by
the program.
mircea_popescu: are you saying
the problem ISN'T after all
that "the compiler can't find 0x10000000000000000" as you originalyl stated, but
that it can't be arsed
to compare
to 0xffffffffffffffff instead ?
mircea_popescu: which fundamental reasons entirely consist of "alf
the bee dog with his magical black and white spots vision managed
to read
the expliciting of
the < vs <= difference SIX
TIMES and ignore it every
time"
mircea_popescu: because if
the programmer said
the number 10,
the compiler is NOT at liberty
to invent magic number 11.
mircea_popescu: and
therefore question for
type Foo is range 0 .. 10 must always be, is foo <= 10 ; not is foo < 11
mircea_popescu: i'm not interested in picking anything. bound checking is
to be done by comparing
TO
THE BOUND not
to some other random value picked by
the compiler.
mircea_popescu: DO NOT implement bounds checking as "smaller
than bound +1". DO implement bounds checking as "smaller or equal
than bound".
mircea_popescu: dude, stop picking
the irrelevant. pick
the meat of what i say.
mircea_popescu: so basically, what my mind has strained from
this convo, is
that ada implements bound checking badly ; in
that it (wrongly) assumes
that it can always source a larget item
to compare
to, like < size+1.
mircea_popescu: the
thing is called modular exponentiation you know :D