|
FlapYoJacks posted:There’s something nice about going back to the simplicity of C and bare-metal programming. Been doing that for a bit for a small client of the business and it’s nice. Just me, registers, and pointers. I had to play with a few thousand lines of bare metal C recently. I spent about six hours doing nothing but fixing data races and buffer overruns. UB is a lot more exciting when there's no memory protection and you're controlling external hardware directly! I'm pretty sure I didn't get even half of it, but it spasmed less when I was done.
|
#
?
Apr 17, 2024 02:21
|
|
|
|
| # ? May 2, 2024 09:41 |
|
|
i mean you can’t actually program the real machine. you can optimize for its capabilities, but it doesn’t have a direct interface and very much isn’t designed to stand on its own separately from the isa. and it’s usually much easier to optimize for its capabilities in a language like c than a language with a less braindead programming model
|
|
#
?
Apr 17, 2024 02:24
|
|
|
akadajet posted:w- what are you trying to say? pretty sure this is an out-of-order execution thing modern cpus just have a massive bank of registers, and a mapping somewhere that says "at this point in the instruction stream, register eax is stored in slot 27". when it dispatches an instruction that writes to that register, it will update the mapping and write it to a different slot. that way that instruction can happen right away even if there are other instructions that still need to read the previous value.
|
|
#
?
Apr 17, 2024 02:27
|
|
|
DELETE CASCADE posted:c is pretty far from bare metal on a modern system and that’s half the problem. registers are a nice example. feel free to use the register keyword in c, chances are it does nothing at all. even your assembly registers aren’t the real registers and haven’t been for decades. it might tickle the feels to program for a nice simple pdp-11 inspired architecture, but that’s not the architecture you have. might as well just be another virtual machine  you can have my 8-bit micros when you pry them from my cold dead hands   also this is microprogrammer erasure and I won't stand for it.  on the pro side, modern cheap "desktop"-class multicores sure can give me a lot of virtual DOS (etc.) machines in one form or another, so they're not entirely useless... eschaton posted:I am now working on getting the VAXstation 100 driver for VMS that was released via DECUS in the 1980s building on VMS 5.5-2 instead of only on VMS 4.7 Athas posted:BLISS is one of those languages that I've heard people (mostly the VMS diaspora) lament the death of, claiming it was a better C. I never understood why it was supposed to be better. (Not saying C is good.) Besides the Digital/VAX/VMS connections, the other primary wellspring was CMU and people connected to it, including folks who went to other places from there, since BLISS originated from CMU once Wulf set up shop there. Indeed, getting a PDP-10 from Digital at CMU seems to have been key to Wulf moving his plans to write an OS forward, and his first step in doing that was to write a new high-level language. Probably the best retrospective I've read on BLISS was Ronald Brender's piece for Software - Practice and Experience, published in 2002. Brender was the primary person responsible for bringing BLISS to DEC. Norman Ramsey's papers archive has a copy: https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf The other "testament" to BLISS I recall offhand was this passing reference in Olin Shivers's paean to T: quote:You could also program the -10 in a beautiful, roughly-C-level language from CMU, called Bliss. I see C and I remember Bliss, and I could weep. EDIT: One thing I totally forgot to mention that I wanted to make sure I included: for anyone who's unfamiliar, both BCPL and BLISS had interesting and seminal texts written about them that I contend are still worthy of study today (but that's probably a very niche opinion): BCPL: The Language and its Compiler by Richards and Whitby-Stevens (available from the Internet Archive), and The Design of an Optimizing Compiler by Wulf, et al. (available from CMU). minidracula fucked around with this message at 04:32 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 04:21
|
|
|
DELETE CASCADE posted:it might tickle the feels to program for a nice simple pdp-11 inspired architecture, but that’s not the architecture you have. might as well just be another virtual machine too bad you don’t actually have access to the actual architecture except by side effect C is as much the lingua franca as assembly at that point
|
|
#
?
Apr 17, 2024 06:05
|
|
|
minidracula posted:I confess a continuing morbid curiosity in BLISS, though in the realm of roughly contemporaneous similar things (typelessness in particular), I found BCPL easier to get one's hands dirty with in a more immediate way if you're not using Digital hardware (real or virtual) and tools, etc. (BCPL, however, still has goto; BLISS does not, and this was seen at the time as a compelling choice and commitment to structured programming.) hell yeah, PM me if you want to fool around with BLISS on a VMS instance I don’t have x86-64 running at all, or IA-64 or Alpha running live right now, but I have an emulated VAX up at least if you want to fool around with BLISS-32 goto has one reasonable use if you don’t have any other sort of structured exception handling, and I bet most BCPL code uses it for exactly that purpose—like my guess, without looking at the code, is that TriPOS probably does that, since UNIX V6/V7 and clones all do it I wish VSI would contribute their LLVM-backed BLISS-64 to the LLVM project, that’s how they did a bunch of the VMS port to x86-64 and the rest was by writing an LLVM backend for MACRO when I was at CMU in the mid-90s, I occasionally saw a reference to BLISS, but by then it had all really aged out, hell Mach had already aged out and Andrew was heading that way quickly too (I did some work for the Cyrus project before I quit school, while friends of mine worked on it through completion and then some) and the functional type theory people basically took over all of CS
|
|
#
?
Apr 17, 2024 06:43
|
|
|
rjmccall posted:i mean you can’t actually program the real machine. you can optimize for its capabilities, but it doesn’t have a direct interface and very much isn’t designed to stand on its own separately from the isa. and it’s usually much easier to optimize for its capabilities in a language like c than a language with a less braindead programming model nice. we can optimize our already-fast computers with only a small cost of using the lang designed from the ground up to create security holes
|
|
#
?
Apr 17, 2024 07:03
|
|
|
We have entered one of the two times per year where I have to worry about macOS preinstalling a gcc=clang I expect that next year I will be posting about Docker-on-macOS having subtle pitfalls.
|
|
#
?
Apr 17, 2024 11:56
|
|
|
Athas posted:I expect that next year I will be posting about Docker-on-macOS having subtle pitfalls. ime the pitfalls are mostly of the following two kinds: (a) you're running on a vm, like a straight up virtualbox instance (i don't actually remember what specific vm arch it uses so don't take that literally) and it does _not_ make it obvious and (b) interop with the osx side is lovely and dog slow and different from any other host it's truly an awful experience especially if you want to mount something stored in osx as a volume
|
|
#
?
Apr 17, 2024 12:49
|
|
|
docker on osx works pretty darn well via rosetta unless you are doing absolutely insane things e: if arch support is your concern. if it’s not, uh, works totally fine ime. as mentioned, it runs a linux VM and executes your containers there. volumes are maybe not as good as on linux (eg, I know permissions are wonky), but… my homie dhall fucked around with this message at 13:33 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 13:30
|
|
|
Is it worse than WSL? Many of my students use WSL and they don't complain or ask me for help.
|
|
#
?
Apr 17, 2024 13:50
|
|
|
I think WSL is probably better, but for 99% of use cases it's going to be equivalent. The two cases I've run into where it hasn't been nice have been when I wanted to setup some specific networking behavior (where I really just wanted a more transparent layer over namespaces) and having x86 binaries relying on (iirc) obscure legacy libc behavior that rosetta doesn't emulate correctly.
|
|
#
?
Apr 17, 2024 14:05
|
|
|
so here’s an interesting thing happening in languages Sean Baxter has apparently implemented (much of) Rust’s non-lexical lifetimes and borrow checker for C++-the-language. it’s a pretty faithful reproduction of the Rust work, down to using the same reasoning about error messages, and reading his tweet history over the past months shows an astonishing-to-me rate of progress, even with a known-working impl to reference https://x.com/seanbax/status/1778876774832574611    this is pretty incredible, because the only other stuff that seems to be happening around memory safety in C++ is Bjarne making things worse every time he writes publicly Google reached the conclusion a while back that there wasn’t a feasible way to do temporal safety in C++, even, which I guess is why they inflicted Carbon on themselves reluctantly Google’s Perspective on Memory Safety posted:
now there’s a wrinkle: Sean is apparently difficult to work with, even by the standards of the open source and C++ communities, and has been trying to find a company to buy him out on this for Very Large Amounts. the work could be worth many billions to the world if it materially improves memory safety for C++, but that’s still going to be a hard deal to make. nonetheless, Sean seems interested in seeing this work make its way through WG21 (sigh) and into standards, so there’s hope, assuming he gets over his anger that he can’t get other C++ heads to even read the NLL and ‘nomicon literature (I bet there’s more of a story there, though). there is a C++ Foundation somewhat analogous to the Rust Foundation AIUI, but even less effective, and nowhere near being able to write those cheques the C++-insider acquaintance I chatted with about this agreed with me that the most likely path to success was a co-author appearing to assist, and he had one promising candidate in mind. hopefully Sean still gets a lot of credit once it’s all extruded through the standards process; maybe we’ll call it the Baxter Model C++ would be growing safety-by-opt-in, which I think isn’t as good as Rust’s safety-by-default, and Rust is a much nicer (and smaller!) language to work with IMO. but if we don’t have to rewrite a ton of poo poo then honestly I think I’d be OK seeing Rust’s candle flicker out and the energy devoted to making tooling for analysis and upgrading of C++ code very curious to hear rjmccall’s take, to whatever extent he can share it!
|
|
#
?
Apr 17, 2024 14:11
|
|
|
Athas posted:Is it worse than WSL? Many of my students use WSL and they don't complain or ask me for help. the big difference with WSL is that WSL aims to present a general computing environment. you can live entirely within WSL (i do, when i work from home). some things can occasionally be slow, but especially with wsl2 it's kind of a best case experience. on osx, you run the docker image on osx directly, so anything persistent has to live on osx and has to be accessed from osx by the docker image. for the stuff it sounds like you want to tell people to do - "write your programs however you want, but use a docker image for the compiler" - you'll presumably be volume mounting source, binary output, and maybe even binary intermediate (for inspectability) storage into the docker vm from the osx host, and that's going to be pretty annoyingly slow
|
|
#
?
Apr 17, 2024 14:12
|
|
|
You don't have to rewrite your C++ programs, you just shouldn't write the next one in C++. I don't think what the world needs is another layer of sediment in the C++ specification, but I'm reluctant to tell other people what they should spend their time working on.
|
|
#
?
Apr 17, 2024 14:16
|
|
|
is indirecting through a filesystem remount really slow? I thought that path was OK now, but maybe that’s only on Linux alternative might be to have the docker container be long lived, expose its own filesystem over localhost NFS, and then just “docker exec” in it to run the compiler lots of paths to make line up, though, and stuff like inotify probably sucks
|
|
#
?
Apr 17, 2024 14:16
|
|
|
idk when the last time you used shared volumes was, but ime it's plenty fast now
|
|
#
?
Apr 17, 2024 14:18
|
|
|
Athas posted:You don't have to rewrite your C++ programs, you just shouldn't write the next one in C++. the problem is that when you write a program, you are generally writing the part of the iceberg that sticks above the water. “write the next one in Swift” is great, as long as the rest of the iceberg exists in Swift, or you can afford to write that stuff yourself I think having a way to surgically make critical components checkably memory-safe would be likely to make more code safe, faster, than waiting until it is rewritten and deployed in a memory-safe language but you are right that C++ does not lack for complexity!
|
|
#
?
Apr 17, 2024 14:19
|
|
|
If the critical components are the tip of an unsafe C++ iceberg, can you trust them if you only rewrite the tip? And is rewriting in safe C++, using borrowing rules, really much simpler than rewriting in Rust? (Not actually a big Rust fan, more of a C++ hater, anyway rewrite it all in Standard ML.) I'm definitely looking forward to seeing what borrow checker errors in template-generated code will look like.
|
|
#
?
Apr 17, 2024 14:37
|
|
|
like, if this is just that they can safely and without breaking backwards compatibility do a rework of c++ so that existing and future code really is improved then, yeah, that's a huge huge deal. if it in practice can't be applied to old code, and new code that works with old code will be more exception than rule, then the point is a lot less clear. if its only helpful for really new code then rust itself is right there, it is not perfect for everything, but for 99% of stuff it's a great improvement. but, yeah, not going to let perfect be the enemy of the good here. if adding range checks and general pointer validation to c in a way that let you mostly live that life while working with old c code i would take *way* less issue with its overuse.
|
|
#
?
Apr 17, 2024 14:45
|
|
|
Subjunctive posted:is indirecting through a filesystem remount really slow? I thought that path was OK now, but maybe that’s only on Linux my homie dhall posted:idk when the last time you used shared volumes was, but ime it's plenty fast now to be clear (and admittedly this was a bit ago because it was so loving bad I refused to use it anymore) this is only and entirely speaking about osx docker hosts that run full fledged vms for the children. no other host os has this problem as far as I can tell.
|
|
#
?
Apr 17, 2024 16:18
|
|
|
Speaking of the Rosetta emulation, does it only support basic x64 profile, or was I holding it wrong? I tried it in CI to run out x64 tests on m1 machine, but the binary instantly crashed with, IIRC, sigill. I traced it down to us targetting broadwell, which was kinda disappointing.
|
|
#
?
Apr 17, 2024 16:29
|
|
|
colima (containers on linux on macOS) is a pretty decent needs-suiter for me. it qEMUs up a linux host and I can have a docker API or a containerd API for running my containers. yeah, it’s a little overly complex in that it is basically running a VM to run my containers. but for my needs? largely doesn’t matter.
|
|
#
?
Apr 17, 2024 16:31
|
|
|
Xarn posted:Speaking of the Rosetta emulation, does it only support basic x64 profile, or was I holding it wrong? I tried it in CI to run out x64 tests on m1 machine, but the binary instantly crashed with, IIRC, sigill. I traced it down to us targetting broadwell, which was kinda disappointing. I don't think Rosetta supports AVX, AVX2, nor AVX512 (Broadwell supporting AVX and AVX2). https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment
|
|
#
?
Apr 17, 2024 16:32
|
|
|
Cybernetic Vermin posted:like, if this is just that they can safely and without breaking backwards compatibility do a rework of c++ so that existing and future code really is improved then, yeah, that's a huge huge deal. that’s the ambition, and afaik he still uses (most of?) the stock stdlib underneath for his examples. devils will be discovered in the details, I’m sure, but it looks to be on the right track
|
|
#
?
Apr 17, 2024 16:38
|
|
|
i actually already gave my opinion on efforts like that in the c++now talk i gave last year, here: https://youtube.com/watch?v=lgivCGdmFrw. many of the common idioms of c++ are fundamentally incompatible with rust-style ownership, so while of course you can add safe features to c++, and maybe even deprecate all the existing ones, actually adopting them in existing code involves a fairly deep rewrite, and then you’re still stuck with all the other things about c++ that suck. if there’s one thing about c++ that represents a vision faithfully seen through, it’s the iterator-centric library design, and you will note that rust — despite having had its language and library design hijacked by c++ eggheads when servo adoption started — completely throws that out, partly because it sucks, but mostly because it’s deeply incompatible with borrowing. rust uses “iterators” in its stdlib, but they’re very different from c++ iterators
|
|
#
?
Apr 17, 2024 16:47
|
|
|
Subjunctive posted:Sean Baxter has apparently implemented (much of) Rust’s non-lexical lifetimes and borrow checker for C++-the-language. it’s a pretty faithful reproduction of the Rust work, down to using the same reasoning about error messages, and reading his tweet history over the past months shows an astonishing-to-me rate of progress, even with a known-working impl to reference In the screenshot, I notice `std2` and `(*s)^.append`. I think this is evidence you'd need to rewrite all your code anyway. The probable advantage of this approach is that things may be rewritten in smaller increments (e.g. function at a time, instead of file/type/module at a time). That could be a big advantage, but it critically depends on memory safety being the only thing that matters. If Rust or Swift were just "C++ but memory safe" I think they would both be abandoned failures by now. The desire for "C++ but memory safe" comes from (1) the wish that existing C++ code could just be magically fixed without rewriting, widely believed to be impossible, but dreamed of anyway, and (2) frightened C++ programmers not realizing they're wishing for something really undesirable and self-destructive. rjmccall's swift talk that was posted awhile back was in the "C++ successor language" track of a C++ conference. I think it's telling that C++ people at a C++ conference are talking successor languages. People are starting to understand "if we have to rewrite anyway, maybe we should not continue to carry all the awful baggage C++ has". We've learned a lot in 40 years of PL design, and C++ wasn't a great design even 40 years ago. Rust isn't winning "most loved programming language" 8 years running because of memory safety.
|
|
#
?
Apr 17, 2024 17:36
|
|
|
the politics at that conference about who counted as a c++ person were very interesting. i was not a c++ person because i was working on swift — never mind that i've been writing c++ professionally for 15 years, made major contributions to a major c++ compiler, and have a (niche) leadership position in c++ development, i had demonstrated disloyalty and so was an outsider. carbon had a major presence there — they basically brought the whole team — but you could see that people were ambivalent about them; they were making every effort to show the proper respect to c++, but they had a new language with a new name, and so their loyalties were questionable. meanwhile herb sutter presented "c++ 2", which was basically also a whole new language that transpiled (admittedly in a straightforward way) to c++, was not given the same treatment because it preserved the holy name. (not that people weren't skeptical on other grounds.) similarly sean baxter's compiler was a major topic of conversation even then because it's positioned as just a c++ implementation
|
|
#
?
Apr 17, 2024 18:09
|
|
|
I'm surprised C++ people are that loyal to C++ itself. I can sort of see it happen for something like Lisp or Prolog or Haskell or similar highly opinionated or puritanical languages, but C++ always seemed intended as a pragmatic craftsman's tool for some times and places. Leaving aside my snarky C++ dislike for just this sentence, I can accept that C++ is sometimes a good and practical choice, but does anyone really love the language and want to make C++ specifically better, rather than just having access to zero-cost abstractions, metaprogramming, or similar notable C++ features for their programming? I guess I can understand this behaviour if your job is to make C++ tools. (Because of the trauma this surely afflicts on your soul.)
|
|
#
?
Apr 17, 2024 18:31
|
|
|
Athas posted:I'm surprised C++ people are that loyal to C++ itself. I can sort of see it happen for something like Lisp or Prolog or Haskell or similar highly opinionated or puritanical languages, but C++ always seemed intended as a pragmatic craftsman's tool for some times and places. Leaving aside my snarky C++ dislike for just this sentence, I can accept that C++ is sometimes a good and practical choice, but does anyone really love the language and want to make C++ specifically better, rather than just having access to zero-cost abstractions, metaprogramming, or similar notable C++ features for their programming? C++ people are the most cliqueish group i can think of in programming more than people extremely deep into FOSS
|
|
#
?
Apr 17, 2024 18:37
|
|
|
Athas posted:I'm surprised C++ people are that loyal to C++ itself. I can sort of see it happen for something like Lisp or Prolog or Haskell or similar highly opinionated or puritanical languages, but C++ always seemed intended as a pragmatic craftsman's tool for some times and places. Leaving aside my snarky C++ dislike for just this sentence, I can accept that C++ is sometimes a good and practical choice, but does anyone really love the language and want to make C++ specifically better, rather than just having access to zero-cost abstractions, metaprogramming, or similar notable C++ features for their programming? C++ dweebs suck
|
|
#
?
Apr 17, 2024 19:53
|
|
|
if you've invested the time, effort, and brain matter necessary to internalize a large subset of C++'s outrageous quagmire of complexity you gotta rationalize it somehow some people invent better languages, some people quadruple down
|
|
#
?
Apr 17, 2024 20:01
|
|
|
to be fair to the broader community, c++now is specifically a “thought leadership” sort of conference, and you’d expect to find true believers heavily overrepresented there
|
|
#
?
Apr 17, 2024 20:05
|
|
|
SAVE-LISP-AND-DIE posted:C++ dweebs suck the other day in work slack the topic of rust came up. someone mentioned that they knew both rust and c++ and that while rust is cool, it would be difficult for someone to learn without knowing c++ well because they won't know the difference between r-values and l-values. gently caress out of here dude
|
|
#
?
Apr 17, 2024 20:06
|
|
|
r-values are on the right, l-values are on the left
|
|
#
?
Apr 17, 2024 20:09
|
|
|
here i am, stuck in the middle with you
|
|
#
?
Apr 17, 2024 21:00
|
|
|
lol imagine trying to program without understanding the taxonomy of glvalues, prvalues, and xvalues
|
|
#
?
Apr 17, 2024 21:11
|
|
|
rjmccall posted:to be fair to the broader community, c++now is specifically a “thought leadership” sort of conference, and you’d expect to find true believers heavily overrepresented there I find that true believership isn’t generally compatible with the kind of thinking that you want leading other thinking, but that doesn’t make it uncommon indeed
|
|
#
?
Apr 17, 2024 21:25
|
|
|
VikingofRock posted:lol imagine trying to program without understanding the taxonomy of glvalues, prvalues, and xvalues this link and entire page reinforces my outsider view and also adds that i don't think anyone should be writing new C/C++ code in 2024
|
|
#
?
Apr 17, 2024 21:30
|
|
|
|
| # ? May 2, 2024 09:41 |
|
|
i also imagine that C/C++ devs view this kind of harsh ergonomic situation as a badge of pride, some liquid hot magma you have to crawl through to appreciate it
|
|
#
?
Apr 17, 2024 21:31
|
|