|
Sagacity posted:what's a good book on modern compiler design? i.e. a book that has heard about SSA at least and written by someone whose beard has seen a razor in the last five years i do suspect that the best thing to do in 2021 is to read documentation (and maybe even browse some code) around llvm, and then separately do a side of parsing if you want some more complete coverage.
|
#
?
Jan 11, 2021 23:50
|
|
|
|
| # ? Jun 3, 2024 22:34 |
|
|
Sagacity posted:what's a good book on modern compiler design? i.e. a book that has heard about SSA at least and written by someone whose beard has seen a razor in the last five years Try "Engineering a Compiler"? Not sure what level of detail you want, seems like that text is more of a primer than anything.
|
|
#
?
Jan 12, 2021 01:28
|
|
|
rjmccall posted:my beard is going crazy right now, my old razor broke and i haven't been bothered to go to the convenience store allow me to recommend the mühle r41. it’s the best razor ive ever used.
|
|
#
?
Jan 12, 2021 06:39
|
|
|
Eldred posted:Try "Engineering a Compiler"? Not sure what level of detail you want, seems like that text is more of a primer than anything. On behalf of rjmccall thanks everyone for razor tips too
|
|
#
?
Jan 12, 2021 07:50
|
|
|
Sagacity posted:Sounds like a good read, thanks! A primer is indeed fine. I kind of handwavingly know about a lot of the concepts but having all concepts explained in a consistent way will make for some entertaining COVID reading. FWIW I used Modern Compiler Implementation in Java by Appel at least 20 yrs ago and it has a whole chapter on SSA. I have no idea if it's still relevant, but I feel like I learned a lot of fundamentals from it at the time. It looks like later versions of the course I had use the same book but in ML, also published in '98 so similarly dated I assume.
|
|
#
?
Jan 12, 2021 21:55
|
|
|
Ah yes, did you feel that it was easier to follow because instead of pseudo code it actually implemented stuff in Java?
|
|
#
?
Jan 12, 2021 22:39
|
|
|
raminasi posted:tbh f# put me on the path to my personal testing heresy because the code i've been happiest with has been decomposed to the point that most functions are simple enough that unit testing them doesn't really make sense Coworker wrote something like that in the description of a MR I was reviewing. Luckily he is my good friend, so I could just push some failing tests to the branch, assign it back to him, and then share laugh later.  What I am saying is, always write some tests
|
|
#
?
Jan 12, 2021 22:44
|
|
|
Xarn posted:Coworker wrote something like that in the description of a MR I was reviewing. it's hard to respond to this without knowing details, but my initial thoughts are: - were his functions as small and simple as the ones i'm talking about? - were your tests unit tests? - was the value in the tests themselves, or the second pair of eyes? ime "always write some tests" is too broad of a prescription and ends up being a great way to spend time assembling a large corpus of unit tests that substantially increase maintenance burden but do very little to aid with correctness
|
|
#
?
Jan 12, 2021 22:59
|
|
|
is Muchnick looked down upon as a compiler text? I bought it in an eager self-improvement mood the last time I worked on a compiler, and have in the intervening decade+ read about 30 pages
|
|
#
?
Jan 12, 2021 23:46
|
|
|
I simply never write tests
|
|
#
?
Jan 13, 2021 03:20
|
|
|
isn't llvm basically just the thing all the compiler people were saying we should make 20 years sgo
|
|
#
?
Jan 13, 2021 05:41
|
|
|
animist posted:isn't llvm basically just the thing all the compiler people were saying we should make 20 years sgo you mean asm.js i think
|
|
#
?
Jan 13, 2021 05:44
|
|
|
Sagacity posted:Ah yes, did you feel that it was easier to follow because instead of pseudo code it actually implemented stuff in Java? It was a compiler class so writing one was the point. They are fun to build and then you can step through to really see what's going on. If you aren't trying to learn a new programming language at the same time just pick the version that better matches what you know. Both OO and functional languages have some nice abstractions for different parts of the implementation so I don't think it really matters which way you go.
|
|
#
?
Jan 13, 2021 09:23
|
|
|
Subjunctive posted:is Muchnick looked down upon as a compiler text? I bought it in an eager self-improvement mood the last time I worked on a compiler, and have in the intervening decade+ read about 30 pages I dont know if it's a good introductory text, it's got 'Advanced' in the title for a reason and I remember it being fairly light on, like, Parsing 101 stuff as compared to optimisation. It does cover SSA, though.
|
|
#
?
Jan 13, 2021 12:47
|
|
|
The reason I asked is precisely because I know how to write a parser and babby's first compiler, but I was specifically interested in a general overview of slightly more modern techniques. Assuming techniques from the late 90s are still considered modern for compilers, but I guess they are
|
|
#
?
Jan 13, 2021 14:09
|
|
|
tbqh i think the problem area is a bit too sprawling to be usefully treated as a single thing whenever you want to step beyond babbys first. it was historically all put together because compilation was expensive enough that you needed to actually integrate things very carefully (basically designing each step away from single-pass compilation with extreme care). but as things stand parsing, type theory, optimization, designing a runtime, etc. are all fairly complex matters and well treated with careful strict abstractions between them.
|
|
#
?
Jan 13, 2021 15:17
|
|
|
well i don't want to build the next llvm, i just want to get a step beyond babby 
|
|
#
?
Jan 13, 2021 15:42
|
|
|
SSA is early-2000s afaik and that's a big turning point in compiler design, at least the actual code-generating bits. Parsers haven't changed much in the last few decades though.
|
|
#
?
Jan 13, 2021 17:30
|
|
|
Sapozhnik posted:SSA is early-2000s afaik and that's a big turning point in compiler design, at least the actual code-generating bits. meanwhile python just switched their parser to use peg, which does I think date from the early 2000s. a few decades ago people were using lex and yacc, now I barely even see lalr talked about. I’m far from an expert, but as someone who does a lot of parsing I’d say things have changed more than a little.
|
|
#
?
Jan 13, 2021 19:21
|
|
|
Soricidus posted:ssa is definitely older than that, although I’m sure it took a while to catch on. I recall the team working on a Java JIT compiler in the late 90s talking about SSA, which was my introduction to it. I don't know how widely adopted it was in practical compiler circles at that point
|
|
#
?
Jan 13, 2021 19:47
|
|
|
speaking of yacc, the reason I asked is not for any useful purpose, I'm just in the middle of a big yacc shave that started with writing a tilemap scroller for the commodore 64, getting annoyed with the tooling, writing my own macro assembler using rust+nom (which is a parser combinator library) and now thinking of maybe writing a simple medium/high-level lang (not a plang or course) on top of that best case I can brag about the experience during some kind of tech interview
|
|
#
?
Jan 13, 2021 20:08
|
|
|
Sagacity posted:yacc shave mods
|
|
#
?
Jan 13, 2021 20:13
|
|
|
Soricidus posted:ssa is definitely older than that, although I’m sure it took a while to catch on. it’s at least as old as say parser combinators tho. yeah, turns out Lisp compilers were using a design a lot like SSA in the late 1980s
|
|
#
?
Jan 13, 2021 20:58
|
|
|
ssa is an old tech. the basic concept is very good, but i've been arguing for years that a literal translation of ssa is a flawed representation: specifically, having phi "instructions" as magic inputs to a block is a bad way of expressing data flow across basic blocks, and it's better to use a more functional representation, like a sort of restricted cps, where basic blocks have parameters that are satisfied by arguments provided to the terminators in predecessor blocks. the representation already needs this concept to deal with function parameters, and this also works far better with higher-level terminators that want to introduce values into one of their successors, like e.g. a dynamic cast that yields the casted value when it succeeds. you can also just structurally say that data flow merges are only allowed on certain terminators instead of spending a poo poo-ton of effort worrying about what happens if you do a data-flow merge across e.g. a switch. we used block arguments this way in swift's higher level ir, sil, and it's been hugely better llvm ir is also really bad in a number of other ways that have nothing to do with ssa. like the way it deals with local stack allocations is just awful and makes it much harder to generate reasonable stack-use patterns, as well as creating a lot of artificial problems for transformations and higher-level representations embedded in ir. just early mistakes that are almost impossible to fix really the main thing you need to know about ssa is that it's not the end of ir design. there are a lot of decisions that go into making a good ir that supports the analyses and transformations you want to do in your language. good representations often benefit from a lot of high-level structural rules beyond the simple dominance conditions of ssa, like requiring that a certain operation be ended before a certain other operation
|
|
#
?
Jan 13, 2021 21:08
|
|
|
raminasi posted:it's hard to respond to this without knowing details, but my initial thoughts are: dunno, I ain't a mind reader. But most of the functions were single line and combined calls to other functions But my take is, if you are developing something there is about 99% chance that you have some set of functionality requirements, which boil down to "if I do X, I get Y". Whether that maps to unit tests (what do you even define as unit tests? are you of the school of thought that everything but a single class has to be mocked? Or do you prefer to assemble units as close to the production code as possible? I honestly don't care.) or to higher level tests doesn't matter, but you should place those into your test suite. Or make a fool of yourself later, I've done that enough times
|
|
#
?
Jan 14, 2021 09:29
|
|
|
Xarn posted:dunno, I ain't a mind reader. But most of the functions were single line and combined calls to other functions oh i’m fully on board with having a test suite. i just don’t think that what’s commonly described as a “unit test” should be nearly as large a part of it as is generally accepted.
|
|
#
?
Jan 14, 2021 18:01
|
|
|
i hate hate hate the phrase unit test. it is so purposely ambiguous and a source of infinite bikeshedding
|
|
#
?
Jan 14, 2021 19:14
|
|
|
Bloody posted:i hate hate hate the phrase unit test. it is so purposely ambiguous and a source of infinite bikeshedding i hate hate hate the way Vue.js handles tests. "Oh no tests in .vue files are hard to do, just stick to only integration test websites and leave the functions in the vue files as black boxes", which would be fine but my coworkers insist on sticking business logic in them.
|
|
#
?
Jan 14, 2021 19:37
|
|
|
Boiled Water posted:i hate hate hate the way Vue.js handles tests. "Oh no tests in .vue files are hard to do, just stick to only integration test websites and leave the functions in the vue files as black boxes", which would be fine but my coworkers insist on sticking business logic in them. yeah it's almost as if MVC is a fundamentally broken abstraction or something
|
|
#
?
Jan 14, 2021 20:00
|
|
|
Sapozhnik posted:yeah it's almost as if MVC is a fundamentally broken abstraction or something what’s the new hotness
|
|
#
?
Jan 14, 2021 20:22
|
|
|
Boiled Water posted:i hate hate hate the way Vue.js handles tests. "Oh no tests in .vue files are hard to do, just stick to only integration test websites and leave the functions in the vue files as black boxes", which would be fine but my coworkers insist on sticking business logic in them. vue-testing-library, like all the -testing-library libs, is pretty good for this case i also tend to err on not writing unit tests for components but i also find writing cypress tests pretty pleasant so i don't mind too much. do yall do integration tests with a mock backend or a live one? both are useful but if you haven't tried a mock backend you might want to look into it for easy testing of component states that might be hard to get into with a real backend
|
|
#
?
Jan 14, 2021 20:55
|
|
|
Sagacity posted:yacc shave please
|
|
#
?
Jan 14, 2021 21:30
|
|
|
abraham linksys posted:vue-testing-library, like all the -testing-library libs, is pretty good for this case we have five mocks in this horribly overengineered piece of poo poo
|
|
#
?
Jan 14, 2021 21:40
|
|
|
Sweeper posted:what’s the new hotness whatever you're doing now, just pick a different acronym
|
|
#
?
Jan 14, 2021 21:48
|
|
|
Xarn posted:Or make a fool of yourself later, I've done that enough times you can go a long way with this
|
|
#
?
Jan 14, 2021 21:50
|
|
|
Subjunctive posted:you can go a long way with this its best if you leave before acquiring the dunce cap
|
|
#
?
Jan 14, 2021 22:42
|
|
|
Sweeper posted:what’s the new hotness Basecamp just reinvented server side rendering. Maybe it's time to check that out.
|
|
#
?
Jan 14, 2021 23:09
|
|
|
pro tip: just write the backend and have some other guys write the frontend so you dont have to bother with javascript poo poo
|
|
#
?
Jan 15, 2021 07:05
|
|
|
Carthag Tuek posted:pro tip: just write the backend and have some other guys write the frontend so you dont have to bother with javascript poo poo this is the pro move
|
|
#
?
Jan 15, 2021 07:33
|
|
|
|
| # ? Jun 3, 2024 22:34 |
|
|
Carthag Tuek posted:pro tip: just write the backend and have some other guys write the frontend so you dont have to bother with javascript poo poo
|
|
#
?
Jan 15, 2021 20:06
|
|