<cyrozap>
cr1901_modern: Because it's literally only mapping to bits in the device
<cyrozap>
device bitstream, that is
<cyrozap>
Which is different for each chip
<rqou>
oh and btw this was pointed out before, but silego's official tool looks like a vidya :P
<rqou>
as opposed to the normal EDA tool look of "took a time warp forwards from the 80s/90s" :P :P
<cyrozap>
cr1901_modern: The important thing to know is that XML doesn't imply any sensible hierarchy--it gives you the "tools" to do so, but XML users are free to ignore them.
<rqou>
*cough* *cough* plists
<qu1j0t3>
:)
Zarutian has quit [Quit: Zarutian]
promach has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
scrts has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
amclain has quit [Quit: Leaving]
<rqou>
hrm, ghdl knows when you tried to do stupid things like naming your entity "std" :P
<rqou>
or (for even more confusion) "work" :P :P
<rqou>
oh this is fun
<rqou>
inside an entity you can declare a thing named "work"
<rqou>
<insert trololo face here>
<rqou>
yes, it shadows "work" referring to the current library
<rqou>
which is itself a magic implicit declaration
talsit has left ##openfpga [##openfpga]
Bike has quit [Quit: slug gourmet]
digshadow has joined ##openfpga
m_t has joined ##openfpga
lexano has quit [Ping timeout: 240 seconds]
Hootch has joined ##openfpga
pie_ has joined ##openfpga
<rqou>
wow i had to go to durant to find noms again. soon i'll become like lain :P
<rqou>
still refusing to try soylent though
pie_ has quit [Ping timeout: 246 seconds]
m_t has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<egg|egg>
rqou: hmm
<egg|egg>
rqou: in Ada you have a top-level package, Standard
<egg|egg>
I think if you do silly things like declaring a package called Standard (so Standard.Standard really) you can lock yourself out of the standard types eventually :-p
<egg|egg>
(the idea is that if you declare a type Integer, you can still get the standard type as Standard.Integer)
<rqou>
so vhdl also has a package called standard
<rqou>
it lives in a library called std
<egg|egg>
...
<egg|egg>
vhdl's theme seems to be "consistency is overrated"
<rqou>
you can't normally lock yourself out though
<rqou>
all primary library units contain an implicit "use std.standard.all"
<egg|egg>
.all means that in vhdl? O_o
<rqou>
that dumps everything from standard into the current scope (er, "makes them directly visible")
<rqou>
yeah
<egg|egg>
right, that would be use Some_Package in Ada
<rqou>
all is a magic keyword that can exist at the end of certain selected names
<rqou>
it's like importing foo.* in some other languages
<egg|egg>
(e.g. with Ada.Text_IO; use Ada.Text_IO; allows you to use Put_Line as opposed to Ada.Text_IO.Put_Line)
<rqou>
so ada seems to do the same thing
<egg|egg>
if you want to use one thing only, you'd use renames
<rqou>
vhdl makes it explicit
<rqou>
also vhdl has textio not text_io P
<rqou>
:P
<egg|egg>
...
<egg|egg>
so procedure Put_Line(whatever) renames Ada.Text_IO
nurelin has quit [Read error: Connection reset by peer]
<egg|egg>
that way you don't get two ways of making Put_Line only directly visible: you can use a package, or rename a single function
<egg|egg>
but not use a single function
<egg|egg>
similarly you can subtype a type, so you can't rename it
<rqou>
on nvm i think i figured out why i was misremembering a pi symbol existing
<egg|egg>
DF? :-p
<rqou>
the hd44780 default (kana) font has a pi
<rqou>
apparently there were other font sets for the hd44780 and clones but i've only ever seen the kana one
<egg|egg>
rqou: oh also Ada has compile-time arbitrary-precision rationals (Universal_Real, which is a slightly weird type that you can't name)
<rqou>
vhdl has that too
<rqou>
based on language lawyering i believe i don't actually need an arbitrary precision library for them
<egg|egg>
huh
<egg|egg>
I think in Ada you do need it
<rqou>
so VHDL has "The accuracy of the evaluation of a universal expression of type universal_real is at least as good as the
<rqou>
accuracy of evaluation of expressions of the most precise predefined floating-point type supported by the
<rqou>
implementation, apart from universal_real itself."
<rqou>
but since each component of such an expression is also a universal expression, i believe you can truncate at each step
<egg|egg>
uuuh
<egg|egg>
but then the accuracy of the whole universal expression doesn't satisfy that
<rqou>
hrm
<rqou>
so you can definitely do it for universal_integer
<rqou>
If the result is of type
<rqou>
universal_integer, then the values of the operands and the result shall lie within the range of the integer type
<rqou>
with the widest range provided by the implementation, excluding type universal_integer itself.
<rqou>
note the "and the result"
<egg|egg>
rqou: does it have the clause "Furthermore, if a universal expression is a static expression, then the evaluation must be exact." following that, like 83RM?
<rqou>
although i know i'll be asking you to test any possible floating point issues :P
<egg|egg>
oooh
* egg|egg
wags tail
<egg|egg>
(wait do eggs have tails?)
<rqou>
i wonder how spec-compliant ghdl's "use VHPIDIRECT to invoke transcendental functions in libm" is?
<egg|egg>
rqou: so in Ada 95 and later they dropped 4.10, but they have "A static expression is evaluated at compile time except when it is part of the right operand of a static short-circuit control form whose value is determined by its left operand. This evaluation is performed exactly, without performing Overflow_Checks"
<egg|egg>
which means that the same applies
<rqou>
afaik vhdl has nothing like that at all
<rqou>
maybe you shouldn't have <huge num> * <tiny num> in your expressions :P
<egg|egg>
why, that's perfectly fine
<egg|egg>
assuming those are FP
<rqou>
is _this_ why gcc gained gmp+mpfr dependencies?
<egg|egg>
possibly?
<egg|egg>
rqou: in floating point, huge num * tiny num is perfectly fine; it's addition of the same that will screw you over
<rqou>
if <tiny num> is a denormal won't you lose precision?
<egg|egg>
ah, *that tiny*
<egg|egg>
well you won't lose precision *there*
<egg|egg>
the precision may have been lost *when you got the denormal*
<egg|egg>
rqou: but other than that you're just merrily multiplying mantissas, unless they overflow the eggsponents matter not
<egg|egg>
now for additions that's another story entirely
<egg|egg>
I crashed Unity by NaNing things the other day
<egg|egg>
normally the segfaults are in my mod's code, but there they were in Unity :-p
<rqou>
raymond chen of oldnewthing mentioned that apparently the itanium abi was set up with snan traps enabled
<rqou>
that led to lots of fun "uninitialized variable" crashes that only happened on itanium
<rqou>
afaik x86 doesn't normally have fpu traps enabled
nurelin has joined ##openfpga
<egg|egg>
rqou: does VHDL have the concept of bounded error? it might not becaues iirc that's from 95, in 83 that stuff was all erroneous
<rqou>
that term doesn't exist in the spec
<rqou>
what does it do in ada?
<egg|egg>
it's used for uninitialized variables
<egg|egg>
it means "they have some value of their type"
<egg|egg>
rather than "the program is erroneous", Ada's word for "UB"
<rqou>
hrm, i haven't looked deeply at how this part works
<egg|egg>
it was introduced because that made many programs that were just fine erroneous
<egg|egg>
if you used an unitialized variable in a where its value didn't actually matter, that was erroneous in Ada (and that allows the compiler to assume stupid things)
<egg|egg>
in Ada 95, it's bounded error, so the compiler must assume that it has a value of its type
<egg|egg>
which makes such programs fine
<rqou>
i don't know what uninitialized variables do in vhdl or if you could even have them
<egg|egg>
yeah, the situation might differ for HDLs
talsit has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Read error: Connection reset by peer]
lexano has joined ##openfpga
Zarutian has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
promach has quit [Quit: Leaving]
Zarutian has quit [Quit: Zarutian]
amclain has joined ##openfpga
Zarutian has joined ##openfpga
digshadow has quit [Quit: Leaving.]
zino has quit [Remote host closed the connection]
digshadow has joined ##openfpga
azonenberg_work has joined ##openfpga
Hootch has quit [Quit: Leaving]
Hootch has joined ##openfpga
m_t has joined ##openfpga
m_w has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
laintoo_ has joined ##openfpga
laintoo has quit [Ping timeout: 260 seconds]
Hootch has quit [Quit: Leaving]
<azonenberg>
woo lots of VHDL talk here, sounds like work is getting done
ZipCPU|Laptop has joined ##openfpga
digshadow has quit [Quit: Leaving.]
m_t has quit [Quit: Leaving]
m_t has joined ##openfpga
laintoo_ is now known as laintoo
ZipCPU|Laptop has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
<egg|egg>
I'm not so much talking about vhdl as I am blathering on and on about Ada tbh :-p