suspended_state

Just to give this context a little bit more substance, Pascal was designed to work on a mainframe which could address up to 4MB of RAM, with a typical setup of around 1MB (it's actually not the real amounts: the CDC-6600 the values are 128Kwords, but it had 60 bits word). These machine were beasts designed for scientific computation.

The first C compiler was implemented on a PDP-11, which could handle up to 64KB of RAM, and had 16bits words.

I assume that these constraints had a heavy influence on how each language was designed and implemented.

Note that I wasn't aware of all these details before writing this comment, I had to check.

See: http://pascal.hansotten.com/niklaus-wirth/zurich-pascal-comp...

Regarding the C compiler, it is likely that the first version was written in assembly language, which was later "translated" to C.

An early version of the compiler can be found there: https://github.com/theunafraid/first_c_compiler and does look like assembly hand converted to (early) C.

Comment · 9 months ago

I don't really know what you mean by "worst-designed syntax". Do you mean that the design process was bad, or that the result is bad?

Comment · 10 months ago

I'm not sure I understand this article, but the argument you present seems to be that when considering P and NP as relational objects, they don't have the same signature, thus cannot be compared, so the statement "P = NP" is meaningless?

Comment · 10 months ago

You should probably have linked the whole work which is briefly referenced at the end of the article, and isn't yet indexed by search engines. I found it by myself:

https://zenodo.org/records/18107880

Comment · 10 months ago

The linking stage could perhaps be performed at process launch by a privileged task?

See this comment thread: https://news.ycombinator.com/item?id=46494183

Isn't a virtual ISA like an intermediate representation? It doesn't have to include static addresses, only symbolic references, which could be resolved at launch time.

Comment · 10 months ago

What I meant, and indeed it was poorly explained, is that an address shouldn't be just an integer freely manipulable by any instruction. The microcode will obviously know how to an manipulate an address, but the ISA as a whole doesn't have to, and in fact shouldn't, with the exception of a few specific instructions. What I am advocating is that addresses should constitute a separate type, which isn't a simple alias to integers. I think that this is what capabilities are about.

Comment · 10 months ago

> Code has to have addresses for calls and branches.

Does it mean that at that level an address has to be an offset in a linear address space?

If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

Comment · 10 months ago

But that address doesn't have to be visible at the ISA level.

Comment · 10 months ago

There are channels in place to discuss security matters in open source. I am by no mean an expert nor very interested in that topic, but just searching a bit led me to

https://oss-security.openwall.org/wiki/mailing-lists

The good guys are certainly monitoring these channels already.

Comment · 10 months ago

Indeed nobody does that, because it would just be pointless, it doesn't expose the real issue. Is a security vulnerability a symptom, or the real issue though? Doesn't it depends on the purpose of the code containing the bug?