|
"Oh yeah? Hold my beer Stroustrup"
|
#
?
Jun 25, 2019 00:07
|
|
|
|
| # ? May 31, 2024 15:26 |
|
|
has anyone pointed out to the v guy that .v is already in use for verilog
|
|
#
?
Jun 25, 2019 00:17
|
|
|
BobHoward posted:has anyone pointed out to the v guy that .v is already in use for verilog no, but over the weekend i learned that spectre/meltdown are verilog's fault and a better HDL wouldn't allow them
|
|
#
?
Jun 25, 2019 00:28
|
|
|
i thought intel used vhdl internally also what can you go into more depth there
|
|
#
?
Jun 25, 2019 00:32
|
|
|
Suspicious Dish posted:i thought intel used vhdl internally also what can you go into more depth there but no vhdl is european, you think that thrice-reheated cruft goes anywhere near our glorious american cores???
|
|
#
?
Jun 25, 2019 00:35
|
|
|
that dumb compiler is fast because it's small enough to fit in a cpu cache, right?
|
|
#
?
Jun 25, 2019 00:39
|
|
|
also because it doesn't do anything -- it compiles to very horrible C code
|
|
#
?
Jun 25, 2019 00:43
|
|
|
 lang
|
|
#
?
Jun 25, 2019 00:45
|
|
|
JawnV6 posted:no, but over the weekend i learned that spectre/meltdown are verilog's fault and a better HDL wouldn't allow them  I need linksJawnV6 posted:but no vhdl is european, you think that thrice-reheated cruft goes anywhere near our glorious american cores??? layers of irony for those unfamiliar: vhdl was created by the United States DOD as its official HDL, complete with syntax directly lifted from Ada, because DOD. then us industry (outside of defense contractors) basically ignored it and went with verilog instead, while for reasons unclear to me european private industry went the opposite way
|
|
#
?
Jun 25, 2019 00:48
|
|
|
BobHoward posted:
at some point it's not that wrong, you could write some checker that tags data to threads and blows up when something touches another. but that's nowhere near a good enough reason to swap out verilog Suspicious Dish posted:i thought intel used vhdl internally also what can you go into more depth there i did co-simulations that had pieces in both verilog & vhdl, which was just a nightmare. 4value/GLS had better tooling
|
|
#
?
Jun 25, 2019 01:04
|
|
|
JawnV6 posted:no, but over the weekend i learned that spectre/meltdown are verilog's fault and a better HDL wouldn't allow them wait what
|
|
#
?
Jun 25, 2019 01:25
|
|
|
JawnV6 posted:to something on the internet several days ago? i didn't comment, so i have no way to get back to it. doesn't appear to be the MIPS R3000 article fwiw did some googling, found nothing. I did find this academic idea though, you might find it interesting http://www.cs.cornell.edu/projects/secverilog/ not exactly what your idea is i think? and I’m a little skeptical that such an extension can comprehensively find timing channels and other information leakage, but i haven’t actually read any of the papers  agreed that there is a little truthiness in that it should be possible to design a hdl which helps identify these issues in the design stage. but it sounds like your poster was all “it’s because verilog!” rather than the correct “whole industry was blindsided by unforeseen security holes left wide open in virtually all cpu isa specs”. everyone thought it would be enough to strive for correct implementation of their respective isa specs, but the specs p much all say your jobs done if you prevent privilege violations from modifying architecturally visible state. turns out that’s not nearly enough, so here we are quote:the first HDL i used at intel was iHDL - an in-house abomination that mixed all kinds of concerns. domino logic expressed in the source continues to haunt me. like imagine specifying the ADD opcode you wanted to be used under the hood in a python program i have heard of ihdl before but was not aware of such horrors. i know Intel was all about hand tweaked logic and layout for a long time, guess that mentality must have leaked into iHDL
|
|
#
?
Jun 25, 2019 02:46
|
|
|
all hdls are fuckin terrible
|
|
#
?
Jun 25, 2019 06:23
|
|
|
even CλaSH ?
|
|
#
?
Jun 25, 2019 06:54
|
|
|
mystes posted:I only learned about V a day or two ago and I'm already sick if hearing about it. the creator is so sick he doesn’t just have chlamydia or aids or whatnot but an entire library of stds. what the gently caress man save some for the rest of us (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Jun 25, 2019 10:56
|
|
|
whoa really
|
|
#
?
Jun 25, 2019 12:23
|
|
|
echinopsis posted:the creator is so sick he doesn’t just have chlamydia or aids or whatnot but an entire library of stds. what the gently caress man save some for the rest of us this is the kind of humor i come to the funny computer forums for. thanks ech
|
|
#
?
Jun 25, 2019 12:26
|
|
|
Suspicious Dish posted:this is the kind of humor i come to the funny computer forums for. thanks ech this but unironically
|
|
#
?
Jun 25, 2019 13:46
|
|
|
Captain Foo posted:this but unironically "but doctor," I sob, "the quoted post was in earnest"
|
|
#
?
Jun 25, 2019 16:15
|
|
|
BobHoward posted:did some googling, found nothing. I did find this academic idea though, you might find it interesting http://www.cs.cornell.edu/projects/secverilog/ on a first pass it strikes me as so obnoxious and onerous that no serious design would bother, then if you actually went through the effort the "whole industry blindsided" problem bites where nobody was tracking who put something in a cache to begin with BobHoward posted:agreed that there is a little truthiness in that it should be possible to design a hdl which helps identify these issues in the design stage. but it sounds like your poster was all “it’s because verilog!” rather than the correct “whole industry was blindsided by unforeseen security holes left wide open in virtually all cpu isa specs”. everyone thought it would be enough to strive for correct implementation of their respective isa specs, but the specs p much all say your jobs done if you prevent privilege violations from modifying architecturally visible state. turns out that’s not nearly enough, so here we are i still think you just extend HT everywhere and keep that 1-bit tag on everything and reject usage if it doesn't match. but it probably shaves half a percent of TPC-C or something BobHoward posted:i have heard of ihdl before but was not aware of such horrors. i know Intel was all about hand tweaked logic and layout for a long time, guess that mentality must have leaked into iHDL that's great until you hit a domino signal that's pre-charging every half cycle. or guess the wrong input and get hurtled backwards in time to the beginning of the simulation eschaton posted:even CλaSH ?
|
|
#
?
Jun 25, 2019 17:31
|
|
|
BobHoward posted:layers of irony for those unfamiliar: vhdl was created by the United States DOD as its official HDL, complete with syntax directly lifted from Ada, because DOD. then us industry (outside of defense contractors) basically ignored it and went with verilog instead, while for reasons unclear to me european private industry went the opposite way
|
|
#
?
Jun 25, 2019 17:42
|
|
|
theres a zillion attempts to just bolt hardware design onto the side of a programming language (i know of, off hand, examples for this in C, C++, python [what the gently caress], haskell, and scala, but i don't doubt that there are more) largely, this approach is doomed to fail, because hardware and software design are very different!!! like, there's a ton for hardware design languages to learn from modern programming languages, but just bolting some poo poo on the side of one isn't gonna get you there in a good way imo
|
|
#
?
Jun 25, 2019 18:48
|
|
|
i saw a cool paper about an asynchronous hdl a while back but afaict nobody's been doing much with it since then
|
|
#
?
Jun 25, 2019 19:25
|
|
|
Suspicious Dish posted:also because it doesn't do anything -- it compiles to very horrible C code no, even dumber. it compiles straight to unoptimized x86 machine code with no form of ir or anything
|
|
#
?
Jun 25, 2019 19:37
|
|
|
Plorkyeran posted:no, even dumber. it compiles straight to unoptimized x86 machine code with no form of ir or anything only on macos. windows and linux require a c compiler
|
|
#
?
Jun 25, 2019 19:46
|
|
|
Bloody posted:largely, this approach is doomed to fail, because hardware and software design are very different!!! like, there's a ton for hardware design languages to learn from modern programming languages, but just bolting some poo poo on the side of one isn't gonna get you there in a good way imo why dont you just lay out all the logic by hand, like grampa babbage did 
|
|
#
?
Jun 25, 2019 20:09
|
|
|
BobHoward posted:
Fwiw Europe's moving over to (System?) Verilog these days. ARM definitely has.
|
|
#
?
Jun 25, 2019 20:35
|
|
|
animist posted:i saw a cool paper about an asynchronous hdl a while back but afaict nobody's been doing much with it since then
|
|
#
?
Jun 25, 2019 20:43
|
|
|
VHDL is crazy verbose, Verilog feels sortof sloppy but it's much nicer to read and write. The world could absolutely use a new take on HDL that doesn't have historical baggage.
|
|
#
?
Jun 25, 2019 21:20
|
|
|
system verilog handled one of the biggest pains with the i/o bundles, just wire up everything with the same name on both sides OVM took out a lot of pain with oddly-sized environments, same checker runs on the same signals in the tiny cluster test env and the giant fullchip simulation there's still a pain point on what language you write the tests/coverage/etc. in (yesterday i found an old copy of my resume with Specman on it) what's your fantasy HDL doing anyway?
|
|
#
?
Jun 25, 2019 21:40
|
|
|
I did a course in bluespec systemverilog once which was pretty neat, it has some nice composability features and things. kinda awkward because of verilog backcompat tho
|
|
#
?
Jun 25, 2019 22:00
|
|
|
bluespec generates bloated garbage appropriate for easily building protocol checkers that can run at HW speed in parallel i seriously think a circuit designer should be carefully selecting the exact case/casex/casez statement that matches their intent, 'composability' doesn't strike me as a useful consideration
|
|
#
?
Jun 25, 2019 22:23
|
|
|
i mean if you're throwing software idiots (like me) at an FPGA it's basically adequate. idk anything about actual ASIC design tho
|
|
#
?
Jun 26, 2019 02:25
|
|
|
Haskell has future as a HDL because both digital circuits and lambda calculus can be interpreted as cartesian closed categories.
|
|
#
?
Jun 26, 2019 08:50
|
|
|
Sinestro posted:Haskell has future as a HDL because both digital circuits and lambda calculus can be interpreted as cartesian closed categories. i sent my chip design to the factory and they shipped me an amazon dash button that i can push to start a wafer run only when i actually need it
|
|
#
?
Jun 26, 2019 20:28
|
|
|
animist posted:i mean if you're throwing software idiots (like me) at an FPGA it's basically adequate. idk anything about actual ASIC design tho v0v okay, idk where you want the bar to be then
|
|
#
?
Jun 26, 2019 23:18
|
|
|
anyway who likes libc????? https://lists.llvm.org/pipermail/llvm-dev/2019-June/133308.html
|
|
#
?
Jun 26, 2019 23:19
|
|
|
JawnV6 posted:anyway who likes libc????? https://lists.llvm.org/pipermail/llvm-dev/2019-June/133308.html was it invented here? no? it can gently caress off then
|
|
#
?
Jun 26, 2019 23:21
|
|
|
i don't understand why google wants to reimplement libc. surely a company so fond of reinventing wheels would have the ambition to create their own library instead of slavishly copying the mistakes of the 1970s
|
|
#
?
Jun 26, 2019 23:51
|
|
|
|
| # ? May 31, 2024 15:26 |
|
|
Soricidus posted:i don't understand why google wants to reimplement libc. surely a company so fond of reinventing wheels would have the ambition to create their own library instead of slavishly copying the mistakes of the 1970s because if they created a new library with new idioms, their target users wouldn't be able to use stackoverflow to do their job
|
|
#
?
Jun 26, 2019 23:57
|
|
