12
$\begingroup$

Let's say I'm interested in designing an instruction set architecture, and I want to know something about a specific design or implementation consideration related to instruction sets and their encodings to inform my encoding design choices. Is such a question on-topic here?

$\endgroup$

2 Answers 2

13
$\begingroup$

I don't see why it wouldn't be. An instruction set is a low-level programming language, and the encoding is its syntax.

$\endgroup$
5
$\begingroup$

I am going to offer a dissenting opinion: I think instruction encoding should be off-topic.

There are lots and lots of encodings that can be seen as programming languages if you take a sufficiently broad definition. For example, a serial protocol for controlling a line printer is, in a sense, an encoding of a programming language. But I don’t think this perspective is very useful:

  • Many of the design requirements for programming languages stem from the fact that they are primarily intended to be read and written by humans. No contemporary ISA is designed with that in mind, and instruction set encodings definitely aren’t.

  • The primary factors that influence instruction encoding are on the decoding side, not the encoding side. Understanding this is essentially hardware expertise—knowledge of how instruction decoding works, familiarity with CPU pipelines, and so on—which has very little overlap with the expertise of our users.

Basically, I just don’t think those questions make sense here because I don’t think programming language experts are equipped to answer them. You need to ask CPU engineers.

Of course, the design of assembly languages that are genuinely intended to be written by humans (which are rare these days but not completely gone) is on-topic: those are languages for humans with many of the usual PL human–computer interaction challenges. But those programmers are interacting with instruction mnemonics, so the actual encoding remains an implementation detail.

$\endgroup$
10
  • 1
    $\begingroup$ I think you make a good point, but I don't think "primarily intended to be read and written by humans" is a good test for what languages are on-topic here. This test would exclude bytecode languages, for example. $\endgroup$
    – kaya3
    Commented Jul 5, 2023 at 2:34
  • $\begingroup$ @kaya3-supportthestrike Bytecode design is a language implementation question, not a language design question. ISA encodings are neither. $\endgroup$
    – Alexis King Mod
    Commented Jul 5, 2023 at 2:35
  • 2
    $\begingroup$ Implementing machine code is, surely, a hardware problem. Although a question about emulating or simulating an ISA might be on topic depending on the question... $\endgroup$
    – Pseudonym
    Commented Jul 5, 2023 at 6:44
  • 1
    $\begingroup$ Is an ISA encoding less so intended to be read or written by humans than, say, a compiler IR? A question about the latter surely seems on-topic. And there are a lot of very specific correspondences between the two (I have tabulated a list here); that makes a prohibition of just one seem rather arbitrary to me. More broadly, cpu design is a specialised subfield of pl implementation; there may happen to be few people on se who know it well, but it doesn't make sense to restrict discussion of pl topics just because they're... $\endgroup$
    – Moonchild
    Commented Aug 14, 2023 at 21:55
  • $\begingroup$ ... ...obscure. $\endgroup$
    – Moonchild
    Commented Aug 14, 2023 at 21:55
  • $\begingroup$ @Moonchild The design of compiler IRs is on-topic because it is critical to language implementations, not because IRs are intended to be read or written by humans. The design of ISA encodings simply is not. $\endgroup$
    – Alexis King Mod
    Commented Aug 14, 2023 at 22:40
  • $\begingroup$ My last sentence contains the main point. A CPU is a language implementation; the differences are in degree, not kind. $\endgroup$
    – Moonchild
    Commented Aug 14, 2023 at 23:09
  • $\begingroup$ @Moonchild A CPU may be a language implementation in some informal sense, but it is simply true that the set of experts designing and implementing programming languages is disjoint from the set of experts designing and implementing CPUs. Which is the point of my answer. $\endgroup$
    – Alexis King Mod
    Commented Aug 14, 2023 at 23:11
  • $\begingroup$ (I guess you mean formal, not informal?) I assure you it is not wholly disjoint. Is it somewhat disjoint? Sure. Specialisation is inevitable—so what? Here you asked a question relating to an analogous split on a much smaller scale. What is the difference? $\endgroup$
    – Moonchild
    Commented Aug 15, 2023 at 0:15
  • $\begingroup$ @Moonchild It is overwhelmingly disjoint! Feel free to provide concrete counterexamples if you’d like, of course. In any case, PL people and compilers people cross-pollinate extensively; the two fields are very close. That is, the distance between working PL researchers and implementors and working compiler researchers and implementors is quite small in the social graph. (Of course, it almost doesn’t matter, since both subjects are explicitly in-scope on this site.) The distance between PL/compilers people and CPU designers is vastly larger. $\endgroup$
    – Alexis King Mod
    Commented Aug 15, 2023 at 0:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .