The Imperium programming language - IPL

[tggzzz]

Leaving ubiquity and popularity and availability aside, what is it about C that give it any kind of status as a systems programming language?

I think it was the concept of a pointer *, which often resolved to a memory address, and that address could be just about anything. Fun things like **thing were simple to write (but maybe not so simple to understand). Also the inclusion of all bit operators and/or/xor/shifts. The standard library includes system type functions like malloc(). A lot of C maps well to machine instructions. And the lack of any nanny code like array bound checking made it fast (but dangerous).

It persists because it is still dangerous. Many languages try to avoid the danger and impose rules that are 95% helpful and 5% frustrating.

In my opinion.

Well, pointers were there in languages that influenced the design of C.

To take a less well known example, consider Algol68. INT x states x is an immutable integer, REF INT x states x is a reference to an integer which is variable, REF  REF INT state x is a pointer to an integer. In Algol 68 the types [10]INT, [10]REF INT, REF[10]INT, REF[10]REF INT are all distinct types and all useful. They closely correspond to the types declared by these C declarations:
typedef const int i[10]; typedef const int *ir[10]; typedef int const *ri[10]; typedef int const *rir[10]; http://www.cap-lore.com/Languages/aref.html

I wonder if the OP realises that Algol68 has many of the features he deems desirable, e.g. "if" can be a variable, and it has symbol set (with alternatives) that work on the various different character sets available on computers at the time. And those are just the start. https://opensource.com/article/20/6/algol68 Truly, Algol is an improvement on most of its successors.

I suspect the OP is unaware of https://rosettacode.org/wiki/Rosetta_Code which gives the same program in many different languages. Examples: there are 68 implementations of Dijkstra's algorithms, and bitwise operations implemented in 144 languages.

That really ought to give him something to "compare and contrast" before committing to something for his language.

Algol68 was the language that most influenced PL/I which I've spoken about at length here, there was also a build of it that accepted Russian keywords, I wonder if you were aware of that.

I was aware of the Russian Algol68 variant thanks. PL/1 never made an impression on this side of the pond. The nearest was a brief flurry of interest in PL/M in the late 70s.

You have seemed to be interested in expressing bit operations. Which of the 144 examples are you thinking of following. Do you prefer the VHDL or Smalltalk concepts? If none of the 144, what will be in your 145th variant?

I have to ask, politely, would you please stop insinuating that I am "unqualified" in some way or other, to discuss this subject? Repeatedly making disparaging remarks and insulting comments is really not what I expect in any forum like this.

It isn't necessarily disparaging to regard someone as unqualified; we have all been unqualified. The key point is what any such person does or does not do to become more qualified. "Learning the literature/history" is necessary.

I went to the trouble in my very first post to mention that I was experienced with compiler design and development, I anticipated that some might be skeptical, that a language is a large undertaking and not to be treated glibly, I know all that and therefore summarized what I had done before.

Yet you continue to insinuate I'm some kind of idiot.

Implementing a compiler and selecting which concepts to use/discard when creating a language have very little in common.

From your statements in this thread, it appears that your experience is limited to a relatively narrow subset of the conceptual types of languages in existence[1]. You fail to engage with suggestions that would widen (possibly beneficially) your understanding. For example, you've completely ignored the possibility of your language including one facility that is very useful in resource-constrained embedded systems: fixed point arithmetic. I don't remember you discussing how multicore/multithread parallel processing will be expressed in your language; that will be critically important in the future.

I try to become less inexperienced in the things that matter to me. Knowing how and when to use languages that are fundamentally and conceptually very different is one such case. OTOH, implementing a compiler is completely uninteresting to me.

[1] e.g. C, Pascal, PL/M, Delphi, Coral-66 are all procedural languages with little difference between them. Conceptually very different languages are VHDL, LISP, Smalltalk, Forth, OCCAM/xC etc etc.

[SiliconWizard]

Leaving ubiquity and popularity and availability aside, what is it about C that give it any kind of status as a systems programming language?

I don't get the premise of your question nor the question itself. It looks like some users that have replied to this have taken it as "what are the features of C that make it appropriate as a system programming language", but that is not what I read in the above, that's not what you asked.

The exact answer to your exact question is obvious - C was explicitely designed to implement an OS. It doesn't need a "status", it's just what it was meant for. And history has proven a long track record of it being appropriate indeed for OS development and low-level stuff in general.

That doesn't mean it's "perfect", or that it's the only language for such endeavours. Other languages have been clearly used, as we already mentioned. A good chunk of the initial MacOS, and base applications was written in Pascal. Wirth designed Oberon as a language for implementing the Oberon OS. Ada has been extensively used for embedded development, and there are a few OSs written in Ada as well.

If the question was "what features of C are key features for a system prog language", then the answer is relatively simple. It has high-level features on par with languages such as Pascal (so not very high-level, bug high-level enough to express abstraction), but can get low-level enough (yes, in particular through the use of pointers, pointer arithmetic, logic operators, function pointers, ...) to address hardware almost directly.

Any modern language that wants to do the same usually resorts to "unsafe" blocks of code, such as Rust, but the idea of unsafe code was already there in Modula-3 - I suggested reading the language report which can be found online. The point is that once you have to use your language for system programming, you'll have to add ways of circumventing all your nice protections by adding "unsafe"constructs.

While that may look like a reasonable approach - instruct the developers to use safe code as much as possible, and restrict unsafe code to the bare minimum - the same can be achieved using multiple languages. Using a very high-level language along with assembly, or along with C for the very low-level code, also works, and is not significantly better or worse than trying to stuff all source code with a single language and resorting to tricks to achieve that.

Just my 2 cents.

[Sherlock Holmes]

Leaving ubiquity and popularity and availability aside, what is it about C that give it any kind of status as a systems programming language?

I think it was the concept of a pointer *, which often resolved to a memory address, and that address could be just about anything. Fun things like **thing were simple to write (but maybe not so simple to understand). Also the inclusion of all bit operators and/or/xor/shifts. The standard library includes system type functions like malloc(). A lot of C maps well to machine instructions. And the lack of any nanny code like array bound checking made it fast (but dangerous).

It persists because it is still dangerous. Many languages try to avoid the danger and impose rules that are 95% helpful and 5% frustrating.

In my opinion.

Well, pointers were there in languages that influenced the design of C.

To take a less well known example, consider Algol68. INT x states x is an immutable integer, REF INT x states x is a reference to an integer which is variable, REF  REF INT state x is a pointer to an integer. In Algol 68 the types [10]INT, [10]REF INT, REF[10]INT, REF[10]REF INT are all distinct types and all useful. They closely correspond to the types declared by these C declarations:
typedef const int i[10]; typedef const int *ir[10]; typedef int const *ri[10]; typedef int const *rir[10]; http://www.cap-lore.com/Languages/aref.html

I wonder if the OP realises that Algol68 has many of the features he deems desirable, e.g. "if" can be a variable, and it has symbol set (with alternatives) that work on the various different character sets available on computers at the time. And those are just the start. https://opensource.com/article/20/6/algol68 Truly, Algol is an improvement on most of its successors.

I suspect the OP is unaware of https://rosettacode.org/wiki/Rosetta_Code which gives the same program in many different languages. Examples: there are 68 implementations of Dijkstra's algorithms, and bitwise operations implemented in 144 languages.

That really ought to give him something to "compare and contrast" before committing to something for his language.

Algol68 was the language that most influenced PL/I which I've spoken about at length here, there was also a build of it that accepted Russian keywords, I wonder if you were aware of that.

I was aware of the Russian Algol68 variant thanks. PL/1 never made an impression on this side of the pond. The nearest was a brief flurry of interest in PL/M in the late 70s.

Are you claiming there were no computer installations in the UK that used PL/I?

You have seemed to be interested in expressing bit operations. Which of the 144 examples are you thinking of following. Do you prefer the VHDL or Smalltalk concepts? If none of the 144, what will be in your 145th variant?

I'm considering symbolic operators for left/right logical shift, right arithmetic shift, rotate left and rotate right, and possibly population count, is that what you're asking me?

I have to ask, politely, would you please stop insinuating that I am "unqualified" in some way or other, to discuss this subject? Repeatedly making disparaging remarks and insulting comments is really not what I expect in any forum like this.

It isn't necessarily disparaging to regard someone as unqualified; we have all been unqualified. The key point is what any such person does or does not do to become more qualified. "Learning the literature/history" is necessary.

The key point is that you are conflating (no doubt intentionally) one's certifications with one's argument. You attack a person's arguments or ideas not by counter arguments but by insults and demeaning comments. One doesn't attack or undermine an argument by attacking or undermining the person presenting the argument. This is a common fallacy committed by inexperienced or disingenuous debaters, those who prefer rhetoric to logic.

If I made some claim to a mathematician, developed some proof of some conjecture, the mathematician would never taint their evaluation of said proof by judging my personality, qualifications, what literature I might have read, what experiences I might have had, he'd argue, respond, on the basis of facts and logic, consider this from Noam Chomsky:

In my own professional work I have touched on a variety of different fields. I've done my work in mathematical linguistics, for example, without any professional credentials in mathematics; in this subject I am completely self-taught, and not very well taught. But I've often been invited by universities to speak on mathematical linguistics at mathematics seminars and colloquia. No one has ever asked me whether I have the appropriate credentials to speak on these subjects; the mathematicians couldn't care less. What they want to know is what I have to say. No one has ever objected to my right to speak, asking whether I have a doctor's degree in mathematics, or whether I have taken advanced courses in the subject. That would never have entered their minds. They want to know whether I am right or wrong, whether the subject is interesting or not, whether better approaches are possible—the discussion dealt with the subject, not with my right to discuss it.

Emphasis mine.

You might want to give his words some serious thought, perhaps get more familiar with the literature as it were.

I went to the trouble in my very first post to mention that I was experienced with compiler design and development, I anticipated that some might be skeptical, that a language is a large undertaking and not to be treated glibly, I know all that and therefore summarized what I had done before.

Yet you continue to insinuate I'm some kind of idiot.

Implementing a compiler and selecting which concepts to use/discard when creating a language have very little in common.

How did you establish that view? it seems to be an opinion and an imprecise one at that. It also now seems you don't doubt my capacity to design and build a real working compiler then, but you doubt my ability to "select concepts" to include in a new language, I can select whatever I want to select though, I started the thread.

From your statements in this thread, it appears that your experience is limited to a relatively narrow subset of the conceptual types of languages in existence[1].

Which of my "statements" are you interpreting that way? This sounds like a "No true Scotsman" argument in the making frankly.

You fail to engage with suggestions that would widen (possibly beneficially) your understanding. For example, you've completely ignored the possibility of your language including one facility that is very useful in resource-constrained embedded systems: fixed point arithmetic.

Would you like me to show you the posts where I advocated fixed point binary and decimal types and arithmetic? perhaps you overlooked them, if I showed them to you they'd prove you wrong on this specific point wouldn't they? Seriously, just say the word and I'll show you those posts.

I don't remember you discussing how multicore/multithread parallel processing will be expressed in your language; that will be critically important in the future.

If you want to discuss that then do so, have you asked me specifically about this area and been ignored? Why do you think I should be raising things that you regard as relevant, just raise them. Berating me for not raising points that you want to raise seems frankly pathetic.

I try to become less inexperienced in the things that matter to me. Knowing how and when to use languages that are fundamentally and conceptually very different is one such case. OTOH, implementing a compiler is completely uninteresting to me.

So just to be very clear you've never personally designed and written lexical analyzers, grammars, parsers, code generators or optimizers then?

[1] e.g. C, Pascal, PL/M, Delphi, Coral-66 are all procedural languages with little difference between them. Conceptually very different languages are VHDL, LISP, Smalltalk, Forth, OCCAM/xC etc etc.

I think you meant that the former are "imperative" languages, but no matter, different languages are different, I'm glad you brought that to my attention.

[Sherlock Holmes]

Leaving ubiquity and popularity and availability aside, what is it about C that give it any kind of status as a systems programming language?

I don't get the premise of your question nor the question itself. It looks like some users that have replied to this have taken it as "what are the features of C that make it appropriate as a system programming language", but that is not what I read in the above, that's not what you asked.

The exact answer to your exact question is obvious - C was explicitely designed to implement an OS. It doesn't need a "status", it's just what it was meant for. And history has proven a long track record of it being appropriate indeed for OS development and low-level stuff in general.

That doesn't mean it's "perfect", or that it's the only language for such endeavours. Other languages have been clearly used, as we already mentioned. A good chunk of the initial MacOS, and base applications was written in Pascal. Wirth designed Oberon as a language for implementing the Oberon OS. Ada has been extensively used for embedded development, and there are a few OSs written in Ada as well.

If the question was "what features of C are key features for a system prog language", then the answer is relatively simple. It has high-level features on par with languages such as Pascal (so not very high-level, bug high-level enough to express abstraction), but can get low-level enough (yes, in particular through the use of pointers, pointer arithmetic, logic operators, function pointers, ...) to address hardware almost directly.

Any modern language that wants to do the same usually resorts to "unsafe" blocks of code, such as Rust, but the idea of unsafe code was already there in Modula-3 - I suggested reading the language report which can be found online. The point is that once you have to use your language for system programming, you'll have to add ways of circumventing all your nice protections by adding "unsafe"constructs.

While that may look like a reasonable approach - instruct the developers to use safe code as much as possible, and restrict unsafe code to the bare minimum - the same can be achieved using multiple languages. Using a very high-level language along with assembly, or along with C for the very low-level code, also works, and is not significantly better or worse than trying to stuff all source code with a single language and resorting to tricks to achieve that.

Just my 2 cents.

We need a definition of "safe" and "unsafe" - do you have one? C# and Java have one but it's inapplicable here. In C# it means:

Most of the C# code you write is "verifiably safe code." Verifiably safe code means .NET tools can verify that the code is safe. In general, safe code doesn't directly access memory using pointers. It also doesn't allocate raw memory. It creates managed objects instead.

It's impossible to write safe code that can corrupt memory, I think that's what this boils down to. Corruption of memory is only possible (that's possible not inevitable) in unsafe code.

Now corrupt of course would need a definition too! But it includes altering memory not "owned" by the executing program or not freeing memory systematically, allowing heap exhaustion, memory leaks.

But what do you mean by "safe"?

By the way all I'm asking here is what core language capabilities would another language need to have, for it to be at least as "good" as C for systems programming, say writing an OS or running on an MCU manipulating A/D converters, UARTS etc with DMA and so on.

Note with the PL/I "model" I'm borrowing here, modifying a pointer's value through a raw arithmetic computation, is to be avoided, eliminated even. In C there are two reasons (so it seems to me) to compute a pointer:

1. As a means of accessing some datum relative to some other (e.g. accessing char array elements given the base address of the array and the element size)
2. Access data in some way not otherwise permitted by the langauge/types.

I might be wrong, but that's my thinking.

If we have no explicit pointer computation and do it all implicitly, why is that bad? why is it inevitable there'll be some cost? surely whatever we code in C can be better coded and at least as fast, by the code gen, the language

But of course take an STM32 device, that (in C) has huge headers with lots n lots of hard coded addresses, raw numbers, that is a need that a language must somehow cater for.

[Sherlock Holmes]

In the coming weeks I expect to have a test parser for this language. I will produce a .Net Core console app that can be run easily in windows with the cmd-line. I'll also include a set of contrived source files that represent variations on valid inputs. Anyone will be able to create a source file and parse it.

If the parser reports a problem yet the code looks legal then we have a grammar bug.
If the parser doesn't report a problem yet the code looks illegal we have a grammar bug.

The goal of such tests is to break the parser, expose faults, hit it hard, hammer it with the most brutal source code that one can.

So this is just an FYI, to let anyone genuinely interested know ahead of time.

I very much value some of the inputs people have posted here, yes there's "noise" but also some extremely helpful points getting raised, I do appreciate it.

[tggzzz]

Algol68 was the language that most influenced PL/I which I've spoken about at length here, there was also a build of it that accepted Russian keywords, I wonder if you were aware of that.

I was aware of the Russian Algol68 variant thanks. PL/1 never made an impression on this side of the pond. The nearest was a brief flurry of interest in PL/M in the late 70s.

Are you claiming there were no computer installations in the UK that used PL/I?

Read what I wrote.

You have seemed to be interested in expressing bit operations. Which of the 144 examples are you thinking of following. Do you prefer the VHDL or Smalltalk concepts? If none of the 144, what will be in your 145th variant?

I'm considering symbolic operators for left/right logical shift, right arithmetic shift, rotate left and rotate right, and possibly population count, is that what you're asking me?

That's part of it. Have a look at VHDL and Smalltalk, see what operations can be done on what, see how operations are expressed.

I have to ask, politely, would you please stop insinuating that I am "unqualified" in some way or other, to discuss this subject? Repeatedly making disparaging remarks and insulting comments is really not what I expect in any forum like this.

It isn't necessarily disparaging to regard someone as unqualified; we have all been unqualified. The key point is what any such person does or does not do to become more qualified. "Learning the literature/history" is necessary.

The key point is that you are conflating (no doubt intentionally) one's certifications with one's argument.

Er, no. This may be a divided by a common language issue.

There is little relationship between a formal certification and how well qualified someone is to make a judgement about something. We've all seen people with bits of paper that shouldn't be let near a keyboard or soldering iron. I'm not certified to be a father, but I am qualified to be one to my daughter.

I went to the trouble in my very first post to mention that I was experienced with compiler design and development, I anticipated that some might be skeptical, that a language is a large undertaking and not to be treated glibly, I know all that and therefore summarized what I had done before.

Yet you continue to insinuate I'm some kind of idiot.

Implementing a compiler and selecting which concepts to use/discard when creating a language have very little in common.

How did you establish that view? it seems to be an opinion and an imprecise one at that. It also now seems you don't doubt my capacity to design and build a real working compiler then...

I'm not surprised you don't understand there is a significant difference. That is consistent with your other statements.

I have never questioned your ability to implement a compiler.

... but you doubt my ability to "select concepts" to include in a new language, I can select whatever I want to select though, I started the thread.

Of course you can select concepts to include in your language. That's not at issue.

The issue is whether the concepts are interesting and/or novel - or just a recapitulation of the past without interesting advantages.

You fail to engage with suggestions that would widen (possibly beneficially) your understanding. For example, you've completely ignored the possibility of your language including one facility that is very useful in resource-constrained embedded systems: fixed point arithmetic.

Would you like me to show you the posts where I advocated fixed point binary and decimal types and arithmetic? perhaps you overlooked them, if I showed them to you they'd prove you wrong on this specific point wouldn't they? Seriously, just say the word and I'll show you those posts.

If you have, and I've no reason to doubt your word, then I've missed them - probably because they have been drowned out by posts about minor tweaks to things that are already commonplace.

I don't remember you discussing how multicore/multithread parallel processing will be expressed in your language; that will be critically important in the future.

If you want to discuss that then do so, have you asked me specifically about this area and been ignored? Why do you think I should be raising things that you regard as relevant, just raise them. Berating me for not raising points that you want to raise seems frankly pathetic.

Such things have been discussed. Nobody has been so crass as to specifically ask for your comments.

I try to become less inexperienced in the things that matter to me. Knowing how and when to use languages that are fundamentally and conceptually very different is one such case. OTOH, implementing a compiler is completely uninteresting to me.

So just to be very clear you've never personally designed and written lexical analyzers, grammars, parsers, code generators or optimizers then?

Certainly not. They are a solved topic within the constraint of a language's specification. They are a vanishingly small part of implementing interesting useful systems, not far off being lost in the noise. I have the same lack of interest in databases, for similar reasons.

I am, however, interested in

• features in language specifications that enable/preclude optimisations in the code emitted by a compiler
• ISA features that enable/preclude processor and machine optimisation
• ways of thinking about problems and expressing solutions that more likely to be correct

And especially how all those interact. Examples: the Mill architecture and DEC Alpha machines with C, and xC/xCORE with hard realtime systems.

[Sherlock Holmes]

I was chatting to the Zig developers earlier, they have replaced the crude C preprocessor with something much better. They allow you to write code (in Zig) that can be executed at compile time and do stuff that's quite impressive. In essence this is very similar to PL/I's preprocessing language and in fact not really a different concept, but preprocessing code and Zig's "comptime" code is similar.

https://kristoff.it/blog/what-is-zig-comptime/

These are very interesting ideas...

[westfw]

I’ve always been nonplussed that the average assembler has a much more capable macro language than the C preprocessor.

[Sherlock Holmes]

Regarding keywords and reserved words. The draft Imperium grammar now has 66 keywords, these are basically tokens in the language that have lexical relevance for parsing rules.

But as I explained, it is trivial to add new ones, nothing can ever break, so that's how the list as been growing as I add keywords like "alias" or "coroutine" or "interrupt" keywords absent from conventional PL/I.

Now consider C, most source say it has (or originally had) 32:

Code: [Select]


auto double int struct
break else long switch
case enum register typedef
char extern return union
const float short unsigned
continue for signed void
default goto sizeof volatile
do if static while

all well and good, but they added 5 for C99 and then 7 for C11, these were real, justifiable, useful language enhancements, but look at how they HAD to be named (and there was always a real risk that some code somewhere had used such names for a type or variable too!).

Code: [Select]

_Alignas _Generic _Thread_local
_Alignof _Noreturn
_Atomic _Static_assert

If this had been Imperium they could have literally added "alignas" and "noreturn" (or "no return" if they'd wanted) and "thread local" (yes with a space even!) and all code, all prior code would compile fine, it is impossible to break a compile by adding a new keyword.

I recently tweaked the grammar to allow an optional keyword to follow and "end" like "end procedure" or "end loop" or "end if" that took two minutes and again, was fully backward compatible.

This is just another reminder of why it is essential to get the grammar right, solid, flexible and extensible BEFORE we do much else.

[tggzzz]

I’ve always been nonplussed that the average assembler has a much more capable macro language than the C preprocessor.

Pre-processors and macros are of significant benefit when creating solutions in assembler.

They slightly simplified the creation of compilers in C, and were a useful hack in 64kbyte machines. At that stage C was regarded as a portable assembler. Nowadays, when C is used for large programs, pre-processors and macros become part of the problem rather than part of the solution.

We have learned a lot over the decades, including  languages which can structure inplementations of solutions. None of the moderbn languages which embody that hard-won experience have pre-processors, for very good reason.

(Clearly I exclude C++ from such modern languages!)

[Sherlock Holmes]

Visual Studio Code

I just discovered that IBM supply a VSCode extension that is aware of their PL/I language, it has syntax highlighting, code completion and more. Here's a quick test drive attached.



This is excellent news because it proves that VSCode extension support is possible for languages that have no reserved words and that code completion is also possible for these languages. In that example the editor reports no syntax errors but has highlighted the variables "if", "then" and "else" as keywords, so that's either a bug in the extension or perhaps a setting alerting me to the fact these identifiers also match keywords, legal but usually not intentionally done.

[Sherlock Holmes]

Multiway branches

The PL/I language has a more powerful construct than the C "switch" statement. I'm going to leverage that and include it in imperium, it's called a "select" statement, here's an example:

Code: [Select]


select (state);
when (1,4,7)
   call flush_buffers(-1);
when (2,3)
   call add_to_buffer(state, status);
   if status > 0 then
      call abort;
when (get_latest_failure(state))
   call log("There was at least one failure");
else
   call log("All is well");
end;


I've modified it a bit and used "else" rather than the PL/I "otherwise" it seems logical to do that since the meaning of "else" and "otherwise" is pretty much the same and the grammar has no issues using that keyword in two types of statements.

There are two important differences, to C's "switch"

1. There is no "fall through" the when clause ends and that's the end of the whole select block.
2. The expressions inside the "when" clauses do not need to be constants, any expression is fine, even a function call.
3. The "when" can also be followed by a "any" or an "all" with obvious meaning.

Ideas, suggestions about this feature are welcome.






   

[Sherlock Holmes]

Operator symbols

Given that I want to support arithmetic/logical shift left/right along with rotate left and right, the question emerges as to what priorities these operators should be given as well as the actual symbol to use for them.

For rotation these sprang to mind:

Rotate left: <@<
Rotate right: >@>

The circularity of the @ seems a reasonable sign for rotation.

Anyway, suggestions welcome.

OK I settled this, these are the tokens for rotate:

Code: [Select]

L_ROTATE:     ('<<@');  // rotate: left bit rotated out rite bit becomes that rotated left bit
R_ROTATE:     ('@>>');  // rotate: rite bit rotated out left bit becomes that rotated rite bit

Here the @ symbol represents the right/left bit who's value is being rotated "in" so to speak.

[brucehoult]

This is just so stupid.

The number of times rotate is used in programs, there is absolutely no disadvantage in typing rotate_right_through_carry(x, i). There is no point in inventing cryptic symbols and discussing what their parsing precedence should be.

Just total bike-shedding.

ISAs that aren't legacy from 8/16 bit machines from the 70s/80s often don't even HAVE a rotate instruction anyway (or a carry flag).

[Sherlock Holmes]

This is just so stupid.

The number of times rotate is used in programs, there is absolutely no disadvantage in typing rotate_right_through_carry(x, i). There is no point in inventing cryptic symbols and discussing what their parsing precedence should be.

Just total bike-shedding.

ISAs that aren't legacy from 8/16 bit machines from the 70s/80s often don't even HAVE a rotate instruction anyway (or a carry flag).

Ahh, yet another offensive, rude, narrow minded post...

Your remarks are those of the knuckle dragger.

How many times is a rotate operation used in programs? seriously? If no language offers a "rotate" operator then HOW THE **** COULD THERE BE any examples of it being used!!

The ARM processor has two rotate operations, ROR (Rotate Right) and RRX (Rotate Right with Extend).

and

The ARM core contains a Barrel shifter which takes a value to be shifted or rotated, an amount to shift or rotate by and the type of shift or rotate. This can be used by various classes of ARM instructions to perform comparatively complex operations in a single instruction. On ARMs up to and including the ARM6 family, instructions take no longer to execute by making use of the barrel shifter, unless the amount to be shifted is specified by a register, in which case the instruction will take an extra cycle to complete.

Take a look at the ARM reference manual, you might learn something, clearly you've just learned something about ARM's ISA that you rather obviously didn't know.

Here's a tip Mr. Halt, if you disagree then say so, don't insult and disparage, just be diplomatic, why must you write "this is just so stupid" rather than "well you might want to consider that..." or "that's certainly interesting, but what if the use cases are very few and far between?" either of which responses would have been better.

The language is new, therefore the notation for a host of operations is an open discussion point, even if some ISAs do not support a hardware rotate instruction so what? the language can still support it. Many of the MCUs out there doing floating point arithmetic do not have instructions for floating point arithmetic so should we not include floating point in a language?

Finally, it is far better to use a dedicated symbol than a culture specific word where possible (clearly you've zero experience of language design). We use + rather than "plus( )" for that reason, have you really never noticed this?

Would you advocate something more like:

Code: [Select]


counter equals zero;

if counter greater than ten then
   counter equals twenty;

total equals counter plus prior_count;

would that be more to your liking? perhaps you'd care to port COBOL to the world of MCUs?

[cfbsoftware]

Multiway branches
Ideas, suggestions about this feature are welcome.

Consider also including ranges as in the Oberon CASE statement e.g. using your syntax:

when ("a".."z","0"..9")

[Sherlock Holmes]

Multiway branches
Ideas, suggestions about this feature are welcome.

Consider also including ranges as in the Oberon CASE statement e.g. using your syntax:

when ("a".."z","0"..9")

Thanks, this is indeed a good idea, in fact range notation is now very common but was unheard of in the 60s when PL/I was nurtured, I will definitely look at this soon!

[brucehoult]

How many times is rotate used in programs? seriously? If no language offers a "rotate" operator then HOW THE **** COULD THERE BE any examples of it being used!!

Very very very rarely.

Rotate is used if and only if the algorithm calls for it, nothing at all to do with the programming language or instruction set.

Take a look at the ARM reference manual, you might learn something, clearly you've just learned something about ARM's ISA that you rather obviously didn't know.

I've been programming ARM CPUs in assembly language since the 1990s, maybe late 80s.

[tggzzz]

This is just so stupid.

The number of times rotate is used in programs, there is absolutely no disadvantage in typing rotate_right_through_carry(x, i). There is no point in inventing cryptic symbols and discussing what their parsing precedence should be.

Just total bike-shedding.

ISAs that aren't legacy from 8/16 bit machines from the 70s/80s often don't even HAVE a rotate instruction anyway (or a carry flag).

Knowing why that is the case would require that the OP understood the evolution in processors that occurred then.

The OP is having fun creating a "VAX language" when other people are creating a "RISC language"   Fettling with a language is a harmless hobby.

Rotate is useful for a few DSP/CRC class algorithms. But those would benefit more from saturating arithmetic or fixed point arithmetic.

[SiliconWizard]

Fettling with a language is a harmless hobby.

Oh yeah, it's fun and harmless. Well, harmless until it mysteriously escapes the computer of its author and starts invading universities and private companies, sometimes for an unknown reason.

[brucehoult]

Knowing why that is the case would require that the OP understood the evolution that occurred then.

I'm curious what combination of characters he is planning to use for:

- CRC32 instruction

- DES and AES instructions

- SHA

- bit reversal in a word

- byte reversal

- selecting bits from one or another source based on a mask

I could go on. There is an infinity of operations, and even hundreds of operations that have been implemented as instructions in some ISA or another. Each very handy and performance-enhancing when needed -- which might be exactly once on the whole machine, in one function in the (hand-written) standard library.

[Sherlock Holmes]

How many times is rotate used in programs? seriously? If no language offers a "rotate" operator then HOW THE **** COULD THERE BE any examples of it being used!!

Very very very rarely.

Rotate is used if and only if the algorithm calls for it, nothing at all to do with the programming language or instruction set.

Mr. Halt, addition is only used if the algorithm calls for it, arithmetic shift is only used if the algorithm calls for it.

Take a look at the ARM reference manual, you might learn something, clearly you've just learned something about ARM's ISA that you rather obviously didn't know.

I've been programming ARM CPUs in assembly language since the 1990s, maybe late 80s.

Yet you never realized they supported a rotate operation? hmm...

[Sherlock Holmes]

Knowing why that is the case would require that the OP understood the evolution that occurred then.

I'm curious what combination of characters he is planning to use for:

- CRC32 instruction

- DES and AES instructions

- SHA

- bit reversal in a word

- byte reversal

- selecting bits from one or another source based on a mask

I could go on. There is an infinity of operations, and even hundreds of operations that have been implemented as instructions in some ISA or another. Each very handy and performance-enhancing when needed -- which might be exactly once on the whole machine, in one function in the (hand-written) standard library.

Rotates are a very small step away from shifts, very very small difference so if we have symbols for left and right shifts its very reasonable to have them for rotates too (which is why the symbols ARE SHIFTS with an additional character), in mathematics and physics we value symmetry, a shift is just a rotate with a discard implied, think about these things before you wade into such discussions like a bull in a china shop, not everyone sees the world through your blinkered, jaded spectacles.

(You even sarcastically mention byte reversal, completely failing to grasp the need for big/little endian capabilities...)

What about XOR? what symbols (if any!) would one use for that in a new language striving to be more helpful than C on hardware programming?

[ataradov]

Rotates are a very small step away from shifts, very very small difference

They are not though. Shifts have the same meaning for various word lengths. Rotates are dependent on the type of the underlying value, so the result depends on how abstract machine and types are implemented.  And that also poorly maps on most hardware.

And what you are doing is really bike-shedding. None of what you are doing is important in a language design.

What about XOR? what symbols (if any!) would one use for that in a new language striving to be more helpful than C on hardware programming?

C has XOR.

And you calling people to look at things is just funny. It is good that you are discovering all those things and all, but it just looks really funny from outside.

[DiTBho]

And you calling people to look at things is just funny. It is good that you are discovering all those things and all, but it just looks really funny from outside.

yup, precisely.

It looked troll-ish, but - reconsidering the whole picture, it's just someone who really believes "EXE" is the binary format used in MPU toolchain

LOL

I wanted to be polite, and reported the only weird case where "EXE" is actually like that.
(SONY's choice, it's always funny to note)

Well, but my blood boiled when I saw labels and gotos, exposed without the minimal concept of RTE.
I can acdept goto in the linux Kernel because Linus knows what he is doing, otherwise, that's really no-goooooooooooooood and harmful.