remexre

> Now what happens, if we're trying to define behavior?

The cell whose address is three billion greater, mod the size of the address space, now has a value of 20?

> If the semantics aren't a direct translation into CPU opcodes, then it's not machine code.

Just because the semantics are defined that way doesn't necessarily mean you couldn't make another implementation that obeys those semantics. For instance, QEMU can perform optimizations on the code it runs, and invalidate them if the program changes those instructions. The semantics of reading from and writing to memory are unchanged by these optimizations, and the implementation doesn't need to do anything special on read.

In my example, the variables are assumed to be addressable, only the address of x was passed via the stack.

Dunno what you mean about having no rules imposed on your code -- you can define the semantics of the language formally and execute them on a machine, same as you can for C, JavaScript, or Prolog.

There's an area of memory into which variables with automatic storage duration are allocated at implementation-defined addrs, at any point exactly those variables have addresses.

Standard Forth, to my knowledge, doesn't have UB and consequently doesn't allow the optimization. That'd just be

    : foo CELL + 20 SWAP ! ;

there. Machine languages also generally don't have this kind of UB, and don't allow the optimization.

It's not impossible to imagine a C without UB, it's just not a particularly desirable language.

That's it -- the optimization is legal because there's no way foo() could modify y, because any (&x)[1] = 20 shenanigans would be UB.

This is how UB is used in optimizations; it's (usually) not that the compiler is finding positions where UB occurs and explicitly choosing to perform mischief, it's performing a bunch of simple and obviously-what-you-want rewrites that are only correct because of UB; otherwise, arbitrary pointer writes are too powerful.

Should a compiler be allowed to optimize:

    int x = 0;
    int y = 42;
    foo(&x);
    bar(y);

to:

    int x = 0;
    foo(&x);
    bar(42);

without performing analysis on foo? If so, how can that optimization be legal without UB?

> So you'd just need a model that can take a textual description of the algorithm as input, and spit out a list of logical errors/flaws.

Right, I'm saying that this is the thing that's dissimilar from handwriting recognition -- the nearer equivalent would an LLM creating a textual description of a novel approach to handwriting recognition, which as far as I'm aware, is beyond current models.

I think you're accidentally making a jump in meta-levels:

The equivalent of an existing handwriting recognizer for e.g. RSA wouldn't be a model that tells you how to crack RSA, it'd be a model that _does_ crack it (maybe by returning a probability distribution over the plaintext that's better than uniform). That feels pretty unlikely to me personally, but maybe that's doable, who knows.

For the standard of "the LLM tells us how to crack RSA," it feels like the equivalent for handwriting recognition would be the LLM outputting a description of a novel algorithm for handwriting recognition (and probably one that isn't just an existing one with some hyperparameters tweaked).

My understanding of the weaknesses of current LLMs is that they're actually pretty bad at that, since they tend to regurgitating existing content when they're able to.

As an aside, to what degree does WASI exist _now_? The spec seems to be in a state of flux as to what the language the spec is written in is, and the language new proposals are written in seems to have grown futures? On the other hand, as far as I can tell, the latest draft spec doesn't look to have support for UDP or scalable notification (epoll, kqueue, etc.), so is that really what people are using their existing software with?

Docker's great win is that you don't even need to recompile your software to use it, much less port it to what's essentially a new non-POSIX operating system.

There's no way the Tariff of Abominations will actually _pass_!

"Anonymous Authors" is typical for a pre-print that might be sent out for blind peer review.

Huh, didn't the best-forgotten BeanShell [0, 1] do a similar thing with the "structs are just another kind of function"?

[0]: https://jcp.org/en/jsr/detail?id=274 [1]: http://beanshell.org/

I thought it runs setup.py

It'd make the chips easier to design, I guess. Maybe motherboards and BIOSes too?

I could imagine a more user-noticeable effect in VM cold-start times, perhaps, though I'd think physical hardware boot times would still be dominated by other things (e.g. actually loading the kernel into memory); the minimal implementation of transitioning from real mode to long mode is a few hundred instructions.

> Something like this is the only thing that would save the x86 architecture before ARM inevitably took over.

Eh, this feels like a rounding error in ISA desirability compared to pointer authentication, or something like CHERI. Sure, it'd be _nice_ to have the legacy stuff cleaned up, but it's not costing much human effort to deal with compared to the effort spent securing native code.

You can't specialize a generic algorithm for specific operations and data structures; in C++ terms, it gives you overloading, not templates.

> require the use of device trees

I think that's the case where it's easy for a vendor to do so; see, for example:

- https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...

- https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...

- https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...

It's useful as a survey of (perhaps somewhat old) opinions about a topic; it's pretty useful as a collection of pros/cons, and imo interesting for its historical context besides.

The problem is that LLVM IR makes breaking changes fairly frequently -- for instance, LLVM 15 made all pointers untyped; where before you'd have a type like *i32, now you just have ptr.

If you're trying to run the same IR on 32-bit and 64-bit devices, I'd expect you'd need to freeze the word size anyway -- if a C or C++ program uses sizeof(), what value gets returned?

Blocking IO doesn't get solved by switching to LLVM either; you can't block in browser WASM because it'd block the JS thread; a WASM engine not attached to a browser has no such issues. (I wish at least one-shot continuations would get added so that this could become a bit easier in the browser, but I understand the hesitancy to do so...)

Doesn't the Flynn effect state that our IQ-valuing society is producing higher-IQ people?

I thought you could implement those in terms of delimited continuations easily by making your top level the delimiter.

I thought the root cause isn't the total number of people, it's the fact that developed-nation lifestyles are a lot more environmentally impactful than developing ones; (6B * current developed-nation avg carbon footprint) > (8B * current global avg carbon footprint)

I wonder if this might be made even more powerful by using a zippers instead of a single left-right pair; then, the generalized-macro could traverse the entire top-level form?

That'd require it to be sound and programs to be total: an infinite loop is a proof of anything, and type system unsoundness leads to false proofs

Also, macOS seems to have copied many of them, so they're worth learning for that too IMO.

I wonder if the structure sociograms like the one at the end of the article could be used as some metric of a species' (social) intelligence

Not "people" happen to live in high crime areas (of course people do anywhere -- crime can't occur without people!), but rich people, who write letters to newspapers that get nationally published, and complain on forums for technologists

The codebase is old and almost entirely in Lisp; parts of the runtime are in C, but they're also not the parts that are getting worked on, because they're not where the bugs are (because so much of it is in Lisp).

Unless Rust has gotten runtime reflection without me hearing about it, I don't think writing the compiler in Rust gives you any special powers in interfacing with Rust. You'd get a lot more of a win from parsing the DWARF of a library when you dlopen() it, and using the type information that exposes to be able to use the full Rust ABI rather than the C ABI.

EDIT: Actually, no, even with runtime reflection, that would only help an interpreter, not a compiler.

That still wouldn't give you the ability to perform template instantiations at runtime though -- for that, you'd need to ship the Rust compiler with your Lisp _applications_, since you might be able to invoke a Rust template with arguments at runtime that hadn't been seen before.

If you're looking at work on building a more modern Lisp compiler, check out SICL or Clasp, though as far as I'm aware, those are both early-ish projects.