DARPA suggests turning old C code automatically into Rust

[tggzzz]

There is a point in this endless "safe language" debate that I find interesting (and yes, I know I talk about it on a regular basis). We have a quite reasonably safer language in many respects, and it's Ada.
The recent revisions of the language make it pretty nice.

Plus the SPARK Ada variant has some very interesting properties. Proponents say that if your program compiles, then it will do what you intend and want

Shame too few people care about correctness.

Syntax? Who cares, I personally don't mind and find it a lot more readable than Rust. It probably icks the Javascript nerds though.

I can't understand people who obsess about syntax and the number of characters they have to type. All I care about is getting to something that works predictably!

Something that icks javascript people is an advantage, a useful bozo filter  (Wot? Me biassed? Shurely shome mishtake)

[DiTBho]

there are much fewer compilers available than for other languages like C, C++ and even Pascal! (For Rust, that's not true at all though, as there is basically only one compiler, which freaks me out, among other things.) But still, GCC does support it and it's open and free. Though users in safety-critical fields tend to favor commercial compilers (which can be very expensive), so I can't tell for sure how robust the Ada GCC front-end is.
 as I don't use it either, although that's something I've been planning on doing for years now.

{ Gcc/ada-core/Gnat, Green Hills Ada } is like comparing two water molecules.
The first belonging to a puddle produced by a summer rain, the second to the Pacific Ocean.

[DiTBho]

I can't understand people who obsess about syntax and the number of characters they have to type.
All I care about is getting to something that works predictably!

Here I am 

I am one of those who obsess about syntax, but not about the number of characters they have to type.
In some ways monads in myC are rather verbose. This is intended.

Since I set myself the goal of staying fairly close to the "C/89" syntax I don't have too many degrees of freedom, however for my myC compiler the syntax of monads is one of the things that particularly obsesses me to the point that I've reviewed it a thousand times and I'm still not satisfied.

It must be elegant, explicit, and synthetic but without giving any possibility to those who use it to create ambiguous or unclear things.
All this is however second to the obsession of making everything damned predictable and observable by the ICE for automatic analysis sessions.
Which *IS* the main obsession!

[DiTBho]

there are much fewer compilers available than for other languages like C, C++ and even Pascal!

... as you know, for myC, the currently supported targets are only two { mips5++, mip32r2 }.

One day, I was drinking my black coffee in a corner of the company bar area. I was looking at the window, it was starting to snow, the first snowflakes were falling - "Java is actually a snowflake that doesn't fall anywhere -  Near me, that voice come from my colleague Elizabeth with her new hit - "there are no real *Java CPUs*, only Java virtual machines" - she smiled, and then she added - "yet people have been running Java on computers for over 20 years" - she waved her hand, pointing to her old cell phone, an object that in the early 2000s seemed damn innovative to have a WABA machine capable of running small Java-v1 applications - "I think myC is somehow like Java, we have a mips32r2 simulator, we have a myC compiler that can compile for that target, why not create a Linux binary extension to automatically start the MIPS32r2-VM whenever you launch something compiled by myC? Then any computer will be able to run applications written in out language!"

Note she said "our language", now she is part of the design-team. So she thinks.

I don't know which of the two things I should worry about 

[tggzzz]

I can't understand people who obsess about syntax and the number of characters they have to type.
All I care about is getting to something that works predictably!

Here I am 

I am one of those who obsess about syntax, but not about the number of characters they have to type.
In some ways monads in myC are rather verbose. This is intended.

Since I set myself the goal of staying fairly close to the "C/89" syntax I don't have too many degrees of freedom, however for my myC compiler the syntax of monads is one of the things that particularly obsesses me to the point that I've reviewed it a thousand times and I'm still not satisfied.

It must be elegant, explicit, and synthetic but without giving any possibility to those who use it to create ambiguous or unclear things.
All this is however second to the obsession of making everything damned predictable and observable by the ICE for automatic analysis sessions.
Which *IS* the main obsession!

I'm much more worried about semantics than syntax. I wholeheartedly support the benefits of allowing improving IDE's ability to make inferences about code. C weenies have no idea how powerful autocompletion can be with a decent language, nor the ability to extract a code block and turn it into a method.

However, if a good syntax makes it easier to get to something that works predictably, then I'm all for it.

But I really don't care about where semicolons are placed, nor the order in which identifier name and type occur.

Mind you, there is an exception: significant whitespace, indicating either scope or where leading spaces/tabs alter the meaning of the rest of the line (Yes, makefiles, I'm looking at you)

[Nominal Animal]

Are you aware of The Mill Processor's and toolchain's architectural concepts?

Somewhat – I'm budget limited, so I haven't played with similar concepts using FPGAs, for example; my real understanding is limited to what I can explore in extended inline assembly and GNU C extensions, really.

Fast context switches (even without switching the task/thread, i.e. for stuff like extremely efficient coroutines), separating data stacks from return address stacks, and especially abstracting memory allocations, I find extremely interesting.  I have dabbled in investigating what would happen if one replaced pointers with handle+offset pairs, with handle being an opaque cookie referring to a contiguous memory segment with obtainable current size (and other things like access permission cookies and such), but no global linear address.  (That would essentially move your memory allocator to kernel and/or hardware, and allow some extremely interesting page translation stuff, making it extremely difficult to exploit unless the bug is in the high-level human-defined logic.  Fully compatible with freestanding C, too.)

Similarly for xCore/xMOS.

I like languages where their white paper states "X and Y have previously been shown to work well and work together, but Z has been omitted because of the problems it causes". In other words, simple modular concepts and abstractions that play well together.

Yep, exactly: interoperability, not encompassing frameworks.

I don't think I was sufficiently clear. My X,Y,Z are language features. A classic example of a "Z" is "multiple inheritance of implementation", omitted because it has been shown to be the source of many language problems.

Ah; "Language features X and Y ...", right.

I obviously agree with that, too, because it shows that even in the original design white paper the authors are trying to learn from history, not ignore it (relying on their "vision" instead, as is usual).

Backwards compatibility also thwarts revolutions.

Gradual changes are like hill-climbing genetic algorithms: at best they find local peaks, but can't jump to hills with higher peaks.

True, but it is obvious to me that most people who try such jumps fail, and end up filling the valleys with crap.  I say it is better to explore the hill first, before deciding to jump to another one.

I'm also not saying I don't want others to jump; I just don't want to wade through the litter of failed attempts.  PHP is a good example: when writing PHP code, I'm fighting the language to get it to do the right thing (albeit less now that Magic Quotes and similar inanities are history).  And Python's WSGI –– hey, lets invent our own web server to script gateway, just because! –– is pretty horrible from performance and low-level security point of view.

I don't know which of the two things I should worry about 

A major reason why I don't want to design my own programming language is that I know I'd have a very hard time releasing control, and letting others evolve it to whatever use and purpose they see fit.

Tools, example code, libraries, my simple PCB designs, I have no problem with letting go.  A full language, with its own paradigm.. you need to put much more of yourself into it.  Doing the development effort in a team from the get go makes it easier, because it's no longer yours alone at any point.

[tggzzz]

Near me, that voice come from my colleague Elizabeth with her new hit - "there are no real *Java CPUs*, only Java virtual machines"...

Wrong. There were a couple of Java microprocessors, and then the commercially successful Azul Java Compute Appliances.

Those processor no longer exist because rapid software optimisations rendered the hardware performance improvements irrelevant. I first saw that phenomenon in the 80s, where JITs vastly increased Smalltalk performance, and something similar happened with Prolog machines.

Made me realise that radical changes needed to be at least 10* better than incumbent technology, and preferably 100* better.

[tggzzz]

Backwards compatibility also thwarts revolutions.

Gradual changes are like hill-climbing genetic algorithms: at best they find local peaks, but can't jump to hills with higher peaks.

True, but it is obvious to me that most people who try such jumps fail, and end up filling the valleys with crap.  I say it is better to explore the hill first, before deciding to jump to another one.

I'm also not saying I don't want others to jump; I just don't want to wade through the litter of failed attempts. 

Well, .... yes.

I've come to regard such wading as the price for keeping technically up to date. Having to do it ensures you actively consider whether the next toy is merely new and shiny, or whether it actually allows you to do things you couldn't do before.

I don't know which of the two things I should worry about 

A major reason why I don't want to design my own programming language is that I know I'd have a very hard time releasing control, and letting others evolve it to whatever use and purpose they see fit.

It is a cliche that hardware designers yearn to create their own processor, whereas software designers yearn to develop their own language.

In both cases the results are usually dismal. Hardware doesn't have the software tooling, and scrotty little Domain Specific Languages quickly grow and metastasise so much  that even their designers no longer understand. The latter happens to mainstream languages too; C++ is the poster child.

[SiliconWizard]

A major reason why I don't want to design my own programming language is that I know I'd have a very hard time releasing control, and letting others evolve it to whatever use and purpose they see fit.

That's understandable. But you don't actually have to release control. Nobody forces you to do that. Unless your goal is to design a language that will be widely used, then in that case, it's kind of unavoidable. So, depends on what your goal is.

Even so, while not completely avoidable, this situation can be largely mitigated by releasing a formal spec to the language, and tools *only* as a reference implementation (and not as the sole artefacts of the project). A formal spec is what many, if not most new programming language projects fail to produce, and that much more easily leads to that situation: people are more prone to tweaking source code than formal specs.

It sure won't solve everything, but languages with a formal spec released early have rarely turned into a big mess going in all directions from people having more ego than skills. So, just my 2 cents.

[coppice]

Wrong. There were a couple of Java microprocessors, and then the commercially successful Azul Java Compute Appliances.

Interesting. Azul came up in two threads on the same day, and I hadn't heard their name in a decade.

[DiTBho]

I wholeheartedly support the benefits of allowing improving IDE's ability to make inferences about code.
C weenies have no idea how powerful autocompletion can be with a decent language, nor the ability to extract a code block and turn it into a method.

talking about obessions, that's #2 in the list 

[DiTBho]

Smalltalk

umm, I remember that on another occasion, always there at the bar where we meet, Elizabeth also mentioned a weird "Smalltalk-RISC machine" made in the 80s? 90s? Dunno, she said a RISC-ish ISA designed to accelerate and facilitate Smalltalk programs.
It must have been an epic failure since no one ever heard of it again.

I vaguely remember a pdf she shared with me about RM2.
It looks a bit "too cool" to walk around the bar with the RE2 under your arm, so I just peeked, but I must still have it somewhere 

[coppice]

Smalltalk

umm, I remember that on another occasion, always there at the bar where we meet, Elizabeth also mentioned a weird "Smalltalk-RISC machine" made in the 80s? 90s? Dunno, she said a RISC-ish ISA designed to accelerate and facilitate Smalltalk programs.
It must have been an epic failure since no one ever heard of it again.

I vaguely remember there being more than one Smalltalk in hardware machine. People loved doing this at one time, and not just in academic settings where all sorts of unlikely to go very far stuff can get funding. There was the P-code machine from Western Digital for Pascal. There were multiple hardware Forth machines. I think someone told me he'd even seen an experimental Spitbol machine.

[Simmed]

haha
is this 1 of those things that get rounded up then everybody gets forced to pay subscription ?

[tggzzz]

Wrong. There were a couple of Java microprocessors, and then the commercially successful Azul Java Compute Appliances.

Interesting. Azul came up in two threads on the same day, and I hadn't heard their name in a decade.

I believe they now sell JVMs with exceptional performance, primarily for big enterprise installations. I remember their GC being particularly good and without stop-the-world hiccups, but that was a decade ago.

Skimming https://www.azul.com/wp-content/uploads/azul-and-gridgain-benchmarks-presentation-1.pdf indicates GC pauses well below 1ms, an impressively real/aggressive/hard GC measurement for the 99.99% percentile, 200GB  heaps. Wow. Just wow.

Being not-Oracle helps them

[coppice]

Wrong. There were a couple of Java microprocessors, and then the commercially successful Azul Java Compute Appliances.

Interesting. Azul came up in two threads on the same day, and I hadn't heard their name in a decade.

I believe they now sell JVMs with exceptional performance, primarily for big enterprise installations. I remember their GC being particularly good and without stop-the-world hiccups, but that was a decade ago.

Skimming https://www.azul.com/wp-content/uploads/azul-and-gridgain-benchmarks-presentation-1.pdf indicates GC pauses well below 1ms, an impressively real/aggressive/hard GC measurement for the 99.99% percentile, 200GB  heaps. Wow. Just wow.

Being not-Oracle helps them

I believe Azul was started by some of the key Java people from Sun, but that was well before Oracle bought Sun.

[tggzzz]

Smalltalk

umm, I remember that on another occasion, always there at the bar where we meet, Elizabeth also mentioned a weird "Smalltalk-RISC machine" made in the 80s? 90s? Dunno, she said a RISC-ish ISA designed to accelerate and facilitate Smalltalk programs.
It must have been an epic failure since no one ever heard of it again.

I vaguely remember a pdf she shared with me about RM2.
It looks a bit "too cool" to walk around the bar with the RE2 under your arm, so I just peeked, but I must still have it somewhere 

Smalltalk On a Risc (SOAR) machine from UCB?

Or there was the Linn Rekursiv, designed by David Harland. Linn, as in the manufacturer of high end turntables; they had money available for speculation.

When we met Harland, it seemed impressive but also that they had bitten off more than he could chew; there was a hint of desperation about the meeting.

The wackypedia article notes "According to a post by a researcher at the University of Strathclyde, while the Rekursiv system was being developed, a new version of the LINGO language was written for the Sun SPARC system which emerged at about this time. It ran twice as fast as the Rekursiv hardware, rendering the effort pointless." That would mirror my previous experience.

https://en.wikipedia.org/wiki/Rekursiv reference 3 is also enlightening. I didn't know any of it, but it doesn't conflict with the little I knew.

[tggzzz]

haha
is this 1 of those things that get rounded up then everybody gets forced to pay subscription ?

Care to enlighten us about what you are talking about?

Hint: this isn't stackexchange/edaboard, use the "quote" button at the top right of each post.

[coppice]

Smalltalk

umm, I remember that on another occasion, always there at the bar where we meet, Elizabeth also mentioned a weird "Smalltalk-RISC machine" made in the 80s? 90s? Dunno, she said a RISC-ish ISA designed to accelerate and facilitate Smalltalk programs.
It must have been an epic failure since no one ever heard of it again.

I vaguely remember a pdf she shared with me about RM2.
It looks a bit "too cool" to walk around the bar with the RE2 under your arm, so I just peeked, but I must still have it somewhere 

Smalltalk On a Risc (SOAR) machine from UCB?

Or there was the Linn Rekursiv, designed by David Harland. Linn, as in the manufacturer of high end turntables; they had money available for speculation.

When we met Harland, it seemed impressive but also that they had bitten off more than he could chew; there was a hint of desperation about the meeting.

The wackypedia article notes "According to a post by a researcher at the University of Strathclyde, while the Rekursiv system was being developed, a new version of the LINGO language was written for the Sun SPARC system which emerged at about this time. It ran twice as fast as the Rekursiv hardware, rendering the effort pointless." That would mirror my previous experience.

https://en.wikipedia.org/wiki/Rekursiv reference 3 is also enlightening. I didn't know any of it, but it doesn't conflict with the little I knew.

"How can I get to an effective CIM system?"
"Well, I wouldn't start from here"

I had completely forgotten about the Rekursiv system. Its sad looking at projects like that, which were a blind alley from day one. Was nobody involved able to convincingly say they were biting off too much for a small company on day one?

[tggzzz]

Smalltalk

umm, I remember that on another occasion, always there at the bar where we meet, Elizabeth also mentioned a weird "Smalltalk-RISC machine" made in the 80s? 90s? Dunno, she said a RISC-ish ISA designed to accelerate and facilitate Smalltalk programs.
It must have been an epic failure since no one ever heard of it again.

I vaguely remember a pdf she shared with me about RM2.
It looks a bit "too cool" to walk around the bar with the RE2 under your arm, so I just peeked, but I must still have it somewhere 

Smalltalk On a Risc (SOAR) machine from UCB?

Or there was the Linn Rekursiv, designed by David Harland. Linn, as in the manufacturer of high end turntables; they had money available for speculation.

When we met Harland, it seemed impressive but also that they had bitten off more than he could chew; there was a hint of desperation about the meeting.

The wackypedia article notes "According to a post by a researcher at the University of Strathclyde, while the Rekursiv system was being developed, a new version of the LINGO language was written for the Sun SPARC system which emerged at about this time. It ran twice as fast as the Rekursiv hardware, rendering the effort pointless." That would mirror my previous experience.

https://en.wikipedia.org/wiki/Rekursiv reference 3 is also enlightening. I didn't know any of it, but it doesn't conflict with the little I knew.

"How can I get to an effective CIM system?"
"Well, I wouldn't start from here"

I had completely forgotten about the Rekursiv system. Its sad looking at projects like that, which were a blind alley from day one. Was nobody involved able to convincingly say they were biting off too much for a small company on day one?

It was an interesting time, a bit of a pre-Cambrian explosion of life-forms/processors. One, of course, has survived: the Acorn RISC Machine.

The reference 3 gives more background.

[coppice]

It was an interesting time, a bit of a pre-Cambrian explosion of life-forms/processors. One, of course, has survived: the Acorn RISC Machine.

ARM succeeded by looking at something that worked, and doing the minimum needed to stretch it into something bigger. However, it didn't really succeed in its own terms. It took DEC and TI to make it move in the market, dragging ARM kicking and screaming behind them.

[tggzzz]

It was an interesting time, a bit of a pre-Cambrian explosion of life-forms/processors. One, of course, has survived: the Acorn RISC Machine.

ARM succeeded by looking at something that worked, and doing the minimum needed to stretch it into something bigger. However, it didn't really succeed in its own terms. It took DEC and TI to make it move in the market, dragging ARM kicking and screaming behind them.

The word "stretch" isn't right.

Wilson and Furber wanted to build their own processor for a small/cheap desktop system. They liked many of the philosophical concepts they had seen in the 6502. They chose to use similar concepts in an entirely original design.

I remember playing with an early Archimedes in 1987 (just before I left Cambridge), when it had a seriously weird filing system organisation and Arthur Norman's excellent C compiler. I was glad I didn't have to use it seriously.

TI only came on the scene much later, in 1993. The significance was not technical, but was that the licencing scheme would work.

DEC's StrongArm came even later, 1995. I don't remember it being significant, but it was outside my interests by then.

[coppice]

TI only came on the scene much later, in 1993. The significance was not technical, but was that the licencing scheme would work.
DEC's StrongArm came even later, 1995. I don't remember it being significant, but it was outside my interests by then.

The ARM was just a niche thing until several American companies saw the potential in it, and shook things up. Apple was another one, with the Newton. They all found it hard to get the Acorn people take the potential of the thing they had seriously. I mentioned TI and DEC, as TI was key in seeing the potential as an embedded core, and DEC saw the potential as a low energy high speed CPU for mobile devices.

[tggzzz]

TI only came on the scene much later, in 1993. The significance was not technical, but was that the licencing scheme would work.
DEC's StrongArm came even later, 1995. I don't remember it being significant, but it was outside my interests by then.

The ARM was just a niche thing until several American companies saw the potential in it, and shook things up. Apple was another one, with the Newton. They all found it hard to get the Acorn people take the potential of the thing they had seriously. I mentioned TI and DEC, as TI was key in seeing the potential as an embedded core, and DEC saw the potential as a low energy high speed CPU for mobile devices.

There were many things happening in the early 90s. If I had to highlight a single one, it was Acorn/ARM's new business model especially licencing the IP for the cores, and letting companies add their own stuff around it. That enabled/encouraged wide interest.

[SiliconWizard]

There is a point in this endless "safe language" debate that I find interesting (and yes, I know I talk about it on a regular basis). We have a quite reasonably safer language in many respects, and it's Ada.
The recent revisions of the language make it pretty nice.

Plus the SPARK Ada variant has some very interesting properties. Proponents say that if your program compiles, then it will do what you intend and want

The recent revisions of the Ada standard have incorporated most of the Spark features. So it's all in standard Ada now. Spark is now pretty much just a subset of Ada for the most part; II haven't studied closely what it removes exactly.

One thing Spark had added was contracts, and it got included in standard Ada a while ago already.

Yeah, not sure what makes people frown upon Ada. Maybe the tooling, as I said - GNAT doesn't seem to be fully trusted for some reason. Again, I don't know if that's justified. And the commercial compilers are freaking expensive. But I'm afraid the main reason is that Ada is just seen as "obsolete" and almost nobody cares to look beyond that prejudice. Funny that C is actually older and not quite seen as badly old as Ada is. I wonder if it's not down to its syntax, Wirthian-like languages being automatically classified as obsolete by the "software industry" (whatever that is).

Fun thought, I'm almost certain that if you took Rust, exactly as is feature-wise, but changed its syntax to a Pascal-like one instead of something C-ish as it is, and renamed it, it would go down the drain.