Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does "inlined" mean? #1814

Open
kersten1 opened this issue Jan 17, 2025 · 16 comments
Open

What does "inlined" mean? #1814

kersten1 opened this issue Jan 17, 2025 · 16 comments

Comments

@kersten1
Copy link
Collaborator

In the 14.1. Specifying Ordering of Atomic Instructions section of the unpriv, there is a para that says this:

"LR/SC can be used to construct lock-free data structures. An example using LR/SC to implement a compare-and-swap function is shown in Example 2. If inlined, compare-and-swap functionality need only take four instructions."

Inlined isn't a word that I can find. Bill T pointed out that it is probably in reference to the inline assembler.

Can someone confirm that?

If so, Does this rewrite make sense?

"LR/SC can be used to construct lock-free data structures. The previous example shows LR/SC implementing a compare-and-swap function. If this example is embedded inline, the compare-and-swap functionality requires only four instructions."

@ved-rivos
Copy link
Collaborator

ved-rivos commented Jan 17, 2025

"Inlined" refers to code that has been directly inserted into a sequence of instructions rather than being referenced as a separate function. It’s a well-understood term in programming and compiler design, often associated with optimizing performance by avoiding the overhead of function calls. However, if clarity is a concern, "embedded inline" might be a better choice for broader audiences. I would suggest: "If embedded inline, the compare-and-swap functionality requires only four instructions."

@aswaterman
Copy link
Member

IMO, “inline” is a sufficiently common verb in the programming languages/compilers context that this sentence is fine as-is.

@kersten1
Copy link
Collaborator Author

@aswaterman @ved-rivos

"inlined" is not a word. I can infer meaning from it based on the common usage of "inline" but it doesn't change the fact that "inlined" is not a word! Additionally, the sentence has an unclear antecedent. You must infer that it is the code from the example that is to appear inline. Plus do all compare-and-swap functionalities that are embedded inline require only four instructions or just this example?

Rather than make the reader infer meaning, we can make this section more clear with a few edits.

We can, however, just remove the "d" from "inlined". It is a less effective fix, but one I can live with.

@aswaterman
Copy link
Member

It's common practice for technical documents to use terminology that's nonstandard in English but is standard within the technical domain. In this community, using "inlined" as a past-tense verb or as an adjective is without a doubt accepted: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=inlined&btnG=

Of course we could rewrite this one sentence, but I'd like to first understand the broader strategy. This document is chockablock with computer-science jargon. Rewriting the document to be entirely free of technical jargon would seem to me to be a questionable expenditure that would ultimately produce something that's less readable.

@allenjbaum
Copy link

allenjbaum commented Jan 21, 2025 via email

@kersten1
Copy link
Collaborator Author

Let’s step back a bit. I have absolutely no problem with the word “inline”. It has a common meaning that even I understand! The word “inline” absolute has a place in technical documentation, including the RISC-V documents. In fact, in my first comment, my suggested rewrite includes the word “inline”. My objection is rather to the form “inlined”.

We are moving towards becoming an ISO standard, which indicates the following spelling references:

8.2 Spelling reference works

Spelling shall be consistent throughout a document. The following reference works for spelling are suggested:

• for English, the Shorter Oxford English Dictionary, the Concise Oxford English Dictionary, the Collins Concise English Dictionary, the Webster’s New World College Dictionary or the Chambers Concise Dictionary;
• for French, Dictionnaire Le Robert, Dictionnaire Larousse and Dictionnaire des difficultés de la langue française (A.V. Thomas, Larousse).

While “inline” appears in all of them, “inlined” does not.

While I agree that this documentation is full of technical jargon, as it should since it is a technical document, I do think that we can make the language easier by rewriting some technical jargon into common word choices.

@aswaterman
Copy link
Member

I'm not trying to make a big deal out of "inlined". My only goal is to derive a general rule, since we're sure to run into this issue repeatedly.

I respectfully disagree with your interpretation of that ISO directive. By my reading, its only requirement is consistency within a document. The references the directive mentions are only suggestions; there's no requirement that a word show up in one of them.

@kersten1
Copy link
Collaborator Author

I am not trying to make a big deal either! If the general rule you are trying to derive is that technical jargon is allowed, I'm all for that! For example, "virtualized" isn't found in most dictionaries. But I would never suggest removing it from technical documentation. Which is why I was asking for a definition of "inlined" just to make sure that I was not missing out on a specialized definition. I will try to be more clear in my requests in the future.

I will also respectively point out that, if consistency is our goal, "inlined" appears one time in all of the priv and unpriv PDFs. Not sure of other docs such as debug.

@allenjbaum
Copy link

allenjbaum commented Jan 21, 2025 via email

@jjscheel
Copy link
Contributor

A couple observations:

  1. The RISC-V ISA manual has been intermittently criticized for its readability and style. The question posed here goes to both areas. I hope we are in agreement that it's worth our time and effort to invest in improving the readability and style of our specifications. I also hope we recognize that while this particular issue seems trivial, there are dozens of issues just like it which will need to be worked to begin to significantly improve readability of our specifications. Thus, while it may appear we're obsessing over a minor issue, we're actually attempting to build a method for handling other readability items as we move forward.
  2. The foundational question (which feels like it's been missed) is what dictionaries we're going to use for guidance ("rules"). ISO suggests some including a couple Oxford variations. Once we have (at least) one, we should then agree to apply it diligently. If we're not going to do so, there's no sense picking one. Yes, there will be exceptions that we can handle, but they should be few (by the definition of exception).
  3. We all have different skill sets: some are experts at designing an ISA, others are experts at designing text. In areas of grammar, we should encourage the grammar experts to propose text improvements (based on the rules, from our agreed upon dictionaries) and let the ISA experts ensure the proposed text does not change the technical meaning. This will be a collaborative process, but it will not function effectively without order.

If we can agree on these three things, I feel like we can make progress. If not, I worry whether and how we will improve.

@radimkrcmar
Copy link
Contributor

  1. [...] we're actually attempting to build a method for handling other readability items as we move forward.

Well said, I'll try to continue along these lines:

  1. The foundational question [...] is what dictionaries we're going to use for guidance. [...]

The ISO suggested dictionaries don't have "inline"; they only have different meanings of "inline", which makes them inapplicable. Similar cases in the future could be more conflicting if we choose dictionaries that do not keep pace with language evolution: here one side claimed "inline" (verb) is not a word while the other side understood it perfectly.

For example following links from inlined can get a reader to an explanation of inlining. LLMs also give a good explanation.
Not that I propose to use either. I just think that having unnecessarily strict guidelines can result in worse cooperation.
(I want to draw similarities to the letter of law against the spirit of the law.)

  1. [...] In areas of grammar, we should encourage the grammar experts to propose text improvements [...] and let the ISA experts ensure the proposed text does not change the technical meaning. [...]

As I see it, this more or less happened here. The "inline" (verb) has not been understood and the replacement phrase "embedded inline" was rejected because it's not a common expression for the intended meaning.

There were a few tangents, but sharing ideas is not an easy process.

@kersten1
Copy link
Collaborator Author

kersten1 commented Jan 23, 2025

Going to try one more time to explain this issue. The word we are discussing is "inlined". The sentence we are looking at is "If inlined, compare-and-swap functionality need only take four instructions." In this case, the word "inlined" is an adjective, describing the example code (as inferred from context - see original issue description for full passage). You can determine this by adding a noun to the sentence. You would not say "If the code inlined" but instead "If the code is inlined." So "code" is the noun, "inlined" is the adjective that is describing the code and "is" is the linking verb, connecting the noun to the adjective.

So let's substitute another adjective, for example "blue". Because blue doesn't have any meaning really in the computer world, let's use a car as the noun. So "If blued, the car moves to the left." Okay so what does "blued" mean in this case? I can infer meaning from the base word "blue" and assume that for some specific reason, blue cars go left. But, this sentence occurs in highly technical information so I need to make sure that "blued" does not have any specialized meaning (and hence, I created the issue). However, it turns out that "blued" means the same as "blue". To bring it full circle, "inlined" has been determined to have the same meaning as "inline".

So now we have what is basically a typo or new technical jargon. We can either fix this single use word by removing the "d" (and preferably adding a noun and linking verb) or we can set up a entry in our glossary and create a new word, complete with definition, as you should always do when introducing technical jargon, even sometimes with jargon that is commonly understood. Again, this new word in "inlined", which is a new word and not "inline", which is not.

We can have a whole discussion about the verbification of nouns and adjectives, but it really isn't a best practice in technical documentation.

@radimkrcmar
Copy link
Contributor

"inlined" in that sentence is a past participle of the verb "inline".

It is not productive to discuss solutions without agreeing on the issue... We want to make a precedent with a good explanation of the underlying cause. So far, I have no idea if the problem is one or more of the following:

  1. participle
  2. past tense
  3. same spelling but a different meaning
  4. domain-specific word

@kersten1
Copy link
Collaborator Author

I don't think we want to use Wiktionary as a technical reference. For example, "blued" is also defined in WIktionary.

If we are trying to stick to the words found in the approved dictionaries, then "inline" is generally defined as an adjective.

If the bad word in my rewrite is "embedded", then I have no problem removing it and changing to "If this example is inline". I'll even go for "If inline". Neither of these suggestions change the original meaning of the sentence. We generally do not use past tense in technical writing as a best practice anyway.

@radimkrcmar
Copy link
Contributor

Yes, that is the root of this issue. Dictionaries don't have the definition of "inline" that is used in this manual.
That alone is not a reason for expulsion for me, though. We should strive to pick the best word.

For example Ada 22 (ISO/IEC 8652:2023) uses inlined:

The implementation shall document the overhead associated with calling machine-code or intrinsic
subprograms, as compared to a fully-inlined call, and to a regular out-of-line call.

Blindly copying others isn't good practice either, so if we look for alternatives, then "If expanded inline," is the most common one (I would never use it as it feels baroque, but it should be understandable).
The tense still needs fixing, but I feel like we can move from here.

@jjscheel
Copy link
Contributor

Before I add a few new thoughts, thanks to all who've been pushing this discussion forward in a productive manner. It may not feel like it, but we're making progress! As a good friend of mine said to me once, "It's not the result, it's the process which matters." It's funny how many situations that applies to in life...

Returning to the problem at hand, I believe we need to agree upon our "rules", i.e one or more dictionaries. Any one we use should be freely available on-line so that we can use them and link to them to answer questions like "is inlined a word?" and "what part of speech is inlined?" Having these would allow us to use the same "rules" for this and similar issues.

If we agree, I propose the @kersten1 and the Doc SIG take the AI to provide the "definitive" list and ensure we put it in our specification writer's guide (Authoring and Editing RISC-V Specifications).

Secondly, I'd propose we should take this time clearly articulated process, in the writer's guide again, for handling our exceptions. Specifically, I'm interested in seeing the Where and the How? Although I think the Where is most simple (our Glossar), I'll be intrigued to see the How. For example, is the Doc SIG going to review and approve all proposed new words or are you going to let me decide (Mom would be so proud if you do). ;-)

If we do these two things, we can all apply the rules and if we still feel we need to create an exception, we know what's needed. Then, we can complete our fun with inlined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants