DARPA suggests turning old C code automatically into Rust - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 06, 2024, 02:32:46 am
content: This one is pretty good:https://www.theregister.com/2024/08/03/darpa_c_to_rust/

author: xrunner
author_rank: Super Contributor
timestamp: August 06, 2024, 02:36:50 am
content: TRACTOR: TRanslating All C TO RustI knew it involved AI as soon as I saw your post.

author: mfro
author_rank: Regular Contributor
timestamp: August 06, 2024, 05:25:31 am
content: QuoteUhh. Not sure if I'd trust the result more than man-made C code...

author: Kleinstein
author_rank: Super Contributor
timestamp: August 06, 2024, 08:14:03 am
content: The idea is getting away from C with it's often unsafe use of pointers and memory handling. A translation of code that uses such features would be tricky.Translating C code automaticly likely makes the code unreadable for humans, even more than the original C. It would than be essentially impossible to find and fix other errors.A manual translation to a new language may actually be a good idea. Sometime a new start / rewirte can make the code clearer and even detect old errors.

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2024, 08:31:55 am
content: This sounds like one of those concepts which can make simple things easy and difficult things impossible.Determining theintentionof a lump of code is non-trivial.Spotting examples of the standard C/C++ problems that cause security and other failures is non-trivial.If those things were easy, they would be in compilers (+ lint, naturally).Waving magic pixie dust (i.e. AI) around won't solve anything interesting.

author: DiTBho
author_rank: Super Contributor
timestamp: August 06, 2024, 08:37:12 am
content: Good use of Tractor: use it to learn RustWrite C code and learn how it should be in RustHappyDays

author: nctnico
author_rank: Super Contributor
timestamp: August 06, 2024, 08:37:31 am
content: Wouldn't it be more usefull to analyse the code for potential buffer overflows and mitigate those?

author: iMo
author_rank: Super Contributor
timestamp: August 06, 2024, 08:46:21 am
content: It seems the gov sector is the easiest to BS audience for the "bleeding edge technology fund risers"..

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2024, 10:00:26 am
content: Quote from: DiTBho on August 06, 2024, 08:37:12 amAs the old joke goes, "If I wanted to gothere, I wouldn't start fromhere".Happy Daze

author: Siwastaja
author_rank: Super Contributor
timestamp: August 06, 2024, 10:46:03 am
content: Quote from: nctnico on August 06, 2024, 08:37:31 amTwo problems:1) this is an already solved problem, with all those actually important codebases already analysed,2) this doesn't sound investor-sexy in any way, look how boring you made it sound like.Therefore, for taxpayer and/or investor money, it needs to begraphenehydrogencloudegge computingAI. And of course, the trend language of the year.

author: nctnico
author_rank: Super Contributor
timestamp: August 06, 2024, 09:37:50 pm
content: OK, sorry. I'll go back to my day job at the sales prevention department.

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2024, 10:43:04 pm
content: Quote from: nctnico on August 06, 2024, 09:37:50 pmMine was at the "going down blind alley" prevention department -semi-seriously, of course.

author: coppice
author_rank: Super Contributor
timestamp: August 06, 2024, 11:13:31 pm
content: Old C code naturally rusts. No action is needed. Try to build many old packages, and you are in for some serious welding of patches over the rust.

author: mfro
author_rank: Regular Contributor
timestamp: August 12, 2024, 07:15:38 am
content: The only real advantage of AI I've seen so far is that it appears BS blockchain talkingdecreased a lot.

author: artag
author_rank: Super Contributor
timestamp: August 12, 2024, 04:43:11 pm
content: How could this possibly be useful ?If it's good, error-less C code, it won't make any difference. It's not that compilers compile unsafely.If it's unsafe C code and the translator creates safe Rust, it has to do something different. So it's not functionally equivalent. The C code might DEPEND on being unsafe to work. How do you know the translation is correct ?At best you end up with something that can be tested (probably requiring fixes) and maintained as Rust. And might be unreadable.Maybe DARPA's next idea will be arming soldiers with dummy rifles so there won't be any friendly fire incidents.

author: radiolistener
author_rank: Super Contributor
timestamp: August 16, 2024, 06:29:19 am
content: Quote from: mfro on August 06, 2024, 05:25:31 amI have the same thoughtsI wouldn't trust to such AI translated code at all, just because I'm often using AI to generate functions. The result, even if it works is usually unusable due to a lot of mistakes which is almost impossible to detect with testing. So it requires to analyze and rework code generated by AI manually. In some cases it may be minor changes, but sometimes AI just unable to generate good code for some tasks and it requires to rewrite it manually from scratch.In my opinion just 1-10% of AI generated code is usable the rest needs to be refactored or rewritten from scratch.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 08:27:42 pm
content: "AI" doesn't actually exist.Look up how ChatGPT really works. But 99.9% of people think it is "AI".There has been minimal progress in generic AI since the 1970s. Lots of vertical applications, sure. Especially in applications involving pattern recognition.

author: coppice
author_rank: Super Contributor
timestamp: October 10, 2024, 10:20:06 pm
content: Quote from: peter-h on October 10, 2024, 08:27:42 pmWell, what they have are elaborate pattern matchers, like a comms equalizer on steroids, and using a similar underlying principle - the correlation quality of a convolution. That is a key part of natural intelligence. Its just not the whole thing. I wonder why the physics Nobel prize didn't go to Norbert Weiner.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 11, 2024, 08:58:54 am
content: Interestingly, I think the concept that is shown in the following site (that I linked to in another thread) also applies here with LLMs :https://tylervigen.com/spurious-correlationsWhat LLMs do (and CNNs in general) is pretty much that: a bunch of correlations on large sets of data, with the goal that it would yield something "intelligent". Makes you ponder.

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 12:40:51 pm
content: Quote from: SiliconWizard on October 11, 2024, 08:58:54 amWe all realise that people need constant reminders that correlation does not mean causation, because the human mind is wired as a pattern matcher, and keeps hooking onto many false correlations. The snag in 2024 is that line has been repeated so many times, dumb people are now claiming that when things correlate that means there is NO causation. The difference between IQ and wisdom/common sense/whatever you want to call it appears to be mostly that IQ is largely pattern matching, and wisdom is the ability to filter out the dumb matches.

author: tggzzz
author_rank: Super Contributor
timestamp: October 11, 2024, 01:44:59 pm
content: Quote from: coppice on October 11, 2024, 12:40:51 pmI don't think anybody claimed Igor Aleksander's 1983 WISARD had IQIt was designed, like modern ML systems, to do pattern matching based on training sets. It worked well in the lab when trained on pictures of tanks and cars, but failed miserably on Luneberger Heath. Nobody could tell why. Eventually they figured out the training set was car adverts and tanks in N Europe, and it was discriminating between sunny days and cloudy days. It is rumoured that Aleksander's colleagues wouldn't recognise his existence on sunny days.Modern ML systems are more sophisticated. They recommend for/against medical treatment based on thefontlabelling the scan.

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 02:15:10 pm
content: Quote from: tggzzz on October 11, 2024, 01:44:59 pmYou keep quoting that ham fisted botched up case like it represents something significant. It just represents what incompetence can achieve on a good day.

author: tggzzz
author_rank: Super Contributor
timestamp: October 11, 2024, 02:20:09 pm
content: Quote from: coppice on October 11, 2024, 02:15:10 pmIt was an early harbinger of things to come.The same fundamental problems exist in modern ML systems in spades, except now they can screw up many peoples' lives.Key concepts:you can't test quality into a system (test==training example), quality has to be designed"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." Modern ML systems can only be the latter

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 02:26:49 pm
content: Quote from: tggzzz on October 11, 2024, 02:20:09 pmAh, the same old rubbish you say each time. An ML system doesn't have to be perfect, since we mostly use these systems to replace highly flawed humans. We only need reasonable confidence that they are no worse than a human. An ML system is quite like a human with no common sense. Well, large numbers of humans have no common sense either, which is probably why bad many ML system responses seem a lot like the dumber of the people around us. When you look at applications where things need to be perfect, like the AI chips floor planning tools that are becoming widely used, the tool doesn't have to be perfect. Like a human doing the floor planning, you expect a lot of errors, so you use rigorous tools to see that the final result gets properly cleaned up.

author: peter-h
author_rank: Super Contributor
timestamp: October 11, 2024, 04:49:09 pm
content: I think the remaining tricky issue with ML is that you mostly don't know how the machine learnt it.Hence the funny cases of recognising a husky (dog) with very high reliability, but actually only because all husky pics used to train the software contained a snow background.I don't know that this has ever been solved - other than by selecting the learning material carefully but then you still don't actually know what the machine is looking at.

author: tggzzz
author_rank: Super Contributor
timestamp: October 11, 2024, 05:07:24 pm
content: Quote from: coppice on October 11, 2024, 02:26:49 pmSo, you are content to be denied essential medical treatment "because the computer says so",and cannot explain why.So, you are content to be incarcerated because - by design - the computer copiesexisting discriminatorypractices,and cannot explain whyI'm not. We deserve better.BTW, both those examples and many more have been observed in the wild; they arepractical not theoretical. FFIstartwith the moderated, high SNR, low volume risks digesthttps://en.wikipedia.org/wiki/RISKS_Digest.Searchable online athttp://catless.ncl.ac.uk/Risks/Note that many of the contributors are giants in their field.

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 06:47:29 pm
content: Quote from: tggzzz on October 11, 2024, 05:07:24 pmWe deserve better than the appalling rate with which doctors and legal people misdiagnose what they are looking at.In the 80s "expert systems", which are essentially Bayesian reasoning machines built from extensive interviewing with a range of human experts, were built for a number of problem domains. The results of trials of these things were very impressive, but they were largely crushed by special interests. We had one that diagnosed configuration and fault issues in our telecoms systems. When it was shown to customers our sales people were threatened with violence, because the customers could see it had the potential to drive them out of their cushy expert jobs. These things could generally do a better job than a human. They encompassed the distilled knowledge of numerous humans, but didn't get stressed, tired, or emotional. I read papers of trials of medical expert systems. Doctors operate in an more emotional and stressful environment than most experts. Expert systems did a great job of diagnosis there. Getting the answers from patients needed by the expert system requires more care by the user, like assessing just what a patient means by "very" in "very painful", but after those value judgements are made by humans, the Bayesian reasoning approach can do a more consistently good job than a human. The only thing I see remaining from that work is one of its most elementary aspects - check lists. Check lists are far more common than in the 1980s, and are considered to greatly reduce human errors in every place they are used. You often have to fight to get even those in place, as humans are generally arrogant and "don't need no check lists".We have ways to have provably better decision making systems in place than we do today, and we don't use them. The problem with ML systems is not what they can do wrong, but what their human masters will have them do wrong for petty emotional reasons. Figures for the number of hospital admissions due to one treatment badly interacting with another are horrifying, and we don't even take that waste of resources and resultant human misery seriously enough to have systems fully rote check multiple treatments for interactions. Personally I'd like to see those expert systems revived. Maybe they can check the ML systems errors.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 11, 2024, 07:05:13 pm
content: coppice, thanks for interesting commentary. What I see kinda-sorta odd is that nowadays the only suggested pattern is "do decision making / create content with AI, use human to check and correct". I would see bigger potential turning that around: use human beings for initial decision making and content creation because humans are still better being very creative, but use AI/ML tocheck and verify their work. This way all of the risks of AI are greatly reduced, but we still can use the potential of it.In other words, if it has anything useful to say, let it do so. Hear the opinion, but don't make it the master of the process.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 11, 2024, 08:42:33 pm
content: Again the main issue here is not with a particular technology, we are a "technological" species.The issue is that some people (and no, not all humans as a whole - who gets to decide?) keep pushing the idea that so-called "AI" should not be just a tool, like every other tool we've ever created, but something that makes us tools instead.Why some are obsessed with that idea, you tell me.

author: tggzzz
author_rank: Super Contributor
timestamp: October 11, 2024, 08:56:50 pm
content: Quote from: coppice on October 11, 2024, 06:47:29 pmWhich bit of "cannot explain why" do you not understand?You can get a doctor to explain "why", andchallenge it. I have had to do that too many timesQuoteAs someone who was active in the research/implementation (i.e. not just field evaluation) of AI systems in the early-mid 80s, I know that is essentially wrong. The AI of the time consisted of, to put it simply, if-then-else rules constructed by eliciting the knowledge from experts.You could easily interrogate the system to see which rules "fired", and hence see the chain of inferences from input to output.That is, to all intents and purposes, impossible with what is now called AI based around Bayesian maths.Quote80s AI systems success was because they distilled expert's knowledge.Modern AI has a large number of examples throw at it, and told "see if you can set millions of of twiddle factors (sorry, 'weights') to copy it".

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 09:18:17 pm
content: Quote from: tggzzz on October 11, 2024, 08:56:50 pmIf the systems you worked on were if-then-else based they were at the very crude end, and of limited ability. Sounds like an early 80s approach. By about 86 or 87 there was a big move to fuzzy logic or true Bayesian approaches. Some things are easy to diagnose with an if-then-else approach, because all the answers to the probing questions are clear yes/no ones. Most things aren't like that. A human expert does things in a Bayesian way, without even thinking much about it. A doctor doesn't go "Patient has a cough. Could be <very long list of possibilities>" and then labouriously work through them. They work is a likelihood based manner. "Patient has a cough. Probably a simple infection. Let's see what other things favour that, or suggest its wrong". Its all weight based. Interestingly, this is the same period where things like data recovery from disks, and decoding in communications channels was moving from hard to maximum likelihood type approaches (e.g. PRML for disks and tape, which started deployment in the early 80s). Simplistic decision slicing has been disappearing from most areas of electronics since that time. None of those can give you a specific reason for their decisions, other than "that's how the weighting worked out".

author: tggzzz
author_rank: Super Contributor
timestamp: October 11, 2024, 09:45:28 pm
content: Quote from: coppice on October 11, 2024, 09:18:17 pmAs I said "to put it simply". Bayesian weights can be and were attached to if-then-else rules.I don't see why you can't understand the difference between rules extracted from experts, and millions of twiddle factors assigned for unknown and unknowable reasons.

author: coppice
author_rank: Super Contributor
timestamp: October 11, 2024, 10:00:00 pm
content: Quote from: tggzzz on October 11, 2024, 09:45:28 pmSo, you were just badly saying what I'd already said.Those expert systems worked, and they practically disappeared. Clearly people aren't interested in solutions that work well, so they get the current round of systems that are the idiot's idea of a smart person. I don't see why you can't figure out that people are happier with something quirky and untrustworthy, than something which works well and makes them feel small.

author: thm_w
author_rank: Super Contributor
timestamp: October 12, 2024, 12:19:59 am
content: Quote from: artag on August 12, 2024, 04:43:11 pmYou test it.QuoteYes that is the entire point... they literally say that in the article.QuoteSurely the intent would be to be readable and maintainable. Its a failure if not.Quote from: Siwastaja on October 11, 2024, 07:05:13 pmBut this topic is about translation, not original content creation.

author: tggzzz
author_rank: Super Contributor
timestamp: October 12, 2024, 11:07:20 am
content: Quote from: coppice on October 11, 2024, 10:00:00 pmNo, I wasn't saying that.Clearly you don't understand the difference.I'll try once more with an analogy, in the knowledge that analogies are dangerous because people tend to latch on to irrelevant aspects.Modern ML systems are like an analogue circuit boards composed of very large numbers of randomly interconnected opamps and trimpots. To get the circuit to "work", you throw lots of waveforms at the input, look at the outputs, and something randomly mutates the trimpot settings until the outputs look OK.Now add yet another different input waveform: you will not be able to predict what the output will be. Mostly it will be similar, but sometimes it will be grossly different.Now reach in and manually change a trimpot or ten. You will not be able to predict to what extent the output will change.QuoteOh, there we agree. Unfortunately

author: coppice
author_rank: Super Contributor
timestamp: October 12, 2024, 03:32:41 pm
content: Quote from: tggzzz on October 12, 2024, 11:07:20 am

author: tggzzz
author_rank: Super Contributor
timestamp: October 12, 2024, 04:53:30 pm
content: Quote from: coppice on October 12, 2024, 03:32:41 pmThe existence or otherwise of free will is a philosophical/religious rathole, with no resolution. Hence it can only be a red herring.It doesn't matter whether the reason was created post hoc. What matters is that thefalse reasoning can be detected and corrected.If an ML gives a false output, which trimpot should be twiddled, and if twiddled what's to guarantee it won't cause something else to break?Suck it and see is the antithesis of good engineering, and is the hallmark of alchemy.People place too much credence in computer outputs, for many reasons including ignorance, laziness, stupidity, malice, financial gain, prejudice, etc."Because the computer says so and it is more than my jobs worth" has long been a vile excuse. Modern ML vastly expands the scope for that to occur, and therefore frequency.

author: coppice
author_rank: Super Contributor
timestamp: October 12, 2024, 04:55:07 pm
content: Quote from: tggzzz on October 12, 2024, 04:53:30 pmIf you are not aware of the hungry judge issue, look it up, and see if you can some back and repeat what you wrote with a straight face.

author: tggzzz
author_rank: Super Contributor
timestamp: October 12, 2024, 05:08:55 pm
content: Looks like a lot of my edits crossed your reply in the aether. It happens. My edited reply is repeated belowThe existence or otherwise of free will is a philosophical/religious rathole, with no resolution. Hence it can only be a red herring.It doesn't matter whether the reason was created post hoc. What matters is that thefalse reasoning can be detected and corrected.If an ML gives a false output, which trimpot should be twiddled, and if twiddled what's to guarantee it won't cause something else to break?Suck it and see is the antithesis of good engineering, and is the hallmark of alchemy.People place too much credence in computer outputs, for many reasons including ignorance, laziness, stupidity, malice, financial gain, prejudice, etc."Because the computer says so and it is more than my jobs worth" has long been a vile excuse. Modern ML vastly expands the scope for that to occur, and therefore frequency.

author: tggzzz
author_rank: Super Contributor
timestamp: October 12, 2024, 05:19:05 pm
content: Quote from: coppice on October 12, 2024, 04:55:07 pmI am well aware that people often exhibit less than commendable behaviour.MLs work by copying existing suboptimal behaviour.You cannot instruct an ML to "do the same as is always done except in special case X do Y", because the X and Y are distributed across millions of trimpots.

author: coppice
author_rank: Super Contributor
timestamp: October 15, 2024, 12:26:17 pm
content: Quote from: tggzzz on October 12, 2024, 05:19:05 pmThe hungry judge study is really interesting. Judges adjudicating parole hearings were monitored for a wide range of things that might influence their decision making. The one issue that stood head and shoulders above all others was how long it had been since the judge ate. I think they were looking beyond actual case factors, for issues like how fresh or tired the judge was, but they finally realised the big deal was stomach contents. So, you could ask the judge how they came to their decision, and they could give you a nice balanced view of the factors they took into account, yet they would miss the tank in the night and day..... I mean just how sated they were at the time.I don't know what mechanisms they use, but when current AI systems don't give the results people want, either being inaccurate or being politically unacceptable, they seem to be able to cook the system very quickly to heavily nudge the outcomes. We saw this with Google's recent mess with every famous historical white figure being rendered as some weird slightly Asian, slightly African, slightly Middle Eastern and slightly native American unisex figure. They responded to that quickly, if incompletely. On the other hand its several years since Google was ridiculed for searches like "white couples" producing only results for couples who were not white. They fixed that for the obvious cases, but I still see searches like "white plastic sheeting" giving me results for people selling every kind of plastic except white. Google's search engine is really badly broken, and we don't really know what it consists of in 2024. Google have made a lot oif TPUs, though, so I guess there is a big ML aspect to their current system.I noticed some videos responding to a recent paper from Apple, about GSM (a high school math test) results from current AI systems. These systems have been achieving high marks, but Apple showed the systems have no analytical ability. If they take the standard GSM questions, and modify them a little major things happen to the accuracy of the results. Things like simply changing the names in questions of the "Jane does X and Fred does Y" type substantial reduces the accuracy of all the AI results. Presumably these questions, in some form, and lots of commentary about the GSM tests, is among the training data. When they changed questions to add some irrelevant detail, that even a low ability human would easily ignore, the AIs took that detail into account, and produced strange results. So, they found no sense of any understanding, merely pattern matching. The researchers seemed shocked to find this. An elaborate pattern matching machine pattern matches quite well, but isn't sophisticated enough to fully generalise the patterns? Whoda thought?So, I guess I have to apologise to tggzzz. I thought people had got past debacles like the "find the tanks among the trees" and similar messes of the 1980s. I guess a new generation of researchers and developers need to learn the old lessons again.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2024, 01:58:40 pm
content: Quote from: coppice on October 15, 2024, 12:26:17 pmBack in the 80s there were many similar examples found while eliciting knowledge from medical experts. There were many reasons, e.g. not realising all the clues they were using when making rules, forgetting edge cases, symptoms with causes that might be inside or outside the sub-medical domain being investigated.Fundamentally knowledge elicitation is an art, an imperfect art.Quote"Responded" is, of course, insufficient. There were famous problems with gorillas being included in the results; oops. Updates were confidently issued - and new failures were almost instantly discovered. Rinse and repeat several times.That is exactly what you would expect from suck-it-and-see "fixes", where nobody can know what the changes are, nor the results spring from the changes.QuoteIf you can'tpredicthow something will behave, then anytime it gives an expected result has to be chance.QuoteDo read comp.risks; it is one of the very few sources I recommend unreservedly to everybody.http://catless.ncl.ac.uk/risksSince it comes out infrequently (<1/week), I use the RSS feedhttp://catless.ncl.ac.uk/risksrss2.xmlto catch the new infelicities.QuoteUnfortunately that is the case.People don't change. Young people continue to think their forebears know nothing. Far too old quote: "When I was 14 I thought my father was a fool. When I was 21 I was amazed at how much he had learned in the past 7 years".My simple attitude:technology X hasfundamentallimitation Ylater on, technology X' is promoted as being betterask how it avoids Ysalesman will normally assert X' doesn't have Y (for software, typically respond with "oh excellent, the Byzantine General's problem / split brain problem / etc has been solved at last; where can I see the published results?)ask how and why notthe lack of an answer almost always reveals that X->Y has been ignored or forgottenWorks with hardware, works with software languages, software products, software environments, works with politics, ........

author: coppice
author_rank: Super Contributor
timestamp: October 15, 2024, 02:17:03 pm
content: Quote from: tggzzz on October 15, 2024, 01:58:40 pmSure, its insufficient, but the speed of their responses mean their solution isn't just trained. Retrains take a long time. They must be using some tampering mechanism. A lot of the worst results I have seen from AI look like the results of poorly thought through human manipulation of results, rather than the results of a neutral training session. So, it looks to me like much of the involvement of humans actually makes things worse. The AI naturally make wacky mistakes. Humans sculpt them to make manipulative mistakes.Have you ever worked with simple trained systems, like echo cancellers or channel equalizers? Even something with a simple goal like "minimise ISI" or "minimise echo" can be surprisingly hard to manually tweak in meaningful ways as you are experimenting to investigate their behaviour during development.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2024, 03:59:27 pm
content: Quote from: coppice on October 15, 2024, 02:17:03 pmCurrently there is a lot ofhidden, um, post-processing being done by humans. Hells teeth, in too many systems is isn't evenpost-processing, e.g. some of the driverless taxis. Scandalous, even dangerous - and just why do companies do it?!QuoteI've worked in radio propagation, so while I've never been involved with (say) a Viterbi decoder, I know the conditions that lead to them being required.There's a generally useful aphorism about any and all sorts of optimisation: "If you know how to optimise, do so. If you don't know how to optimise, randomise". Radio propagation merely follows that rule

author: coppice
author_rank: Super Contributor
timestamp: October 15, 2024, 05:15:31 pm
content: Quote from: tggzzz on October 15, 2024, 03:59:27 pmThere are a lot of "voice recognition" telephone applications which have been working well for more than 20 years. That's because they use entirely human recognition. Some have a clunky speech recognition system working alongside a human, so if some of what is said gets recognised properly it cuts the amount of typing required. When you speak into your cellphone these days the recognition can be pretty good, but recognising across a 3.4kHz bandwidth line, where all the unvoiced sounds merge into one, still isn't that great. There is an interesting psychology, especially in the US, where people would rather deal with a machine than a human. So, to keep these people happy there are various systems which hide a human, and present like a machine. Text to speech has been adequate for that for quite a while.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2024, 05:41:01 pm
content: Quote from: coppice on October 15, 2024, 05:15:31 pmhttps://www.relayuk.bt.com/is something banks use to communicate remotely with deaf customers, which is needed more and more as bank branches close. I presume you have to give the (wo)man-in-the-middle your banking access credentials; I hope that isn't against banks' Ts&Cs!Having a human is fine. What is despicably deceitful isclaimingan automated ML system, but actuallyhavinga Mechanical Turk.

author: coppice
author_rank: Super Contributor
timestamp: October 15, 2024, 05:54:52 pm
content: Quote from: tggzzz on October 15, 2024, 05:41:01 pmI thought the internet would have killed that off by now. I did some work in the early 90s for deaf people to communicate with each other in Chinese. A combination of cell phones with SMS and the internet killed that off long ago. Its amazing how much effort people will go to for simple message exchange when the route most of us use is blocked. Its also amazing how eager deaf people are, regardless of age and other factors, to dump older technologies when something easier to use comes along.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2024, 07:34:20 pm
content: Quote from: coppice on October 15, 2024, 05:54:52 pmFAQs only deal with simple common cases. Chatbots are (unless the airline is stupid!) limited to things in the FAQ. It doesn't take much to exceed that, and you have to deal with so exceeding that is nominally intelligent and imaginative.F2F allows lipreading, but banks are closing branches.That leaves telephone or requires specific equipment.As for "new.things", yes - provided the new thing is affordable, works, and is better than current practice. We both know how frequently new==different and new!=better

author: coppice
author_rank: Super Contributor
timestamp: October 15, 2024, 08:02:07 pm
content: Quote from: tggzzz on October 15, 2024, 07:34:20 pmMost of my encounters with my bank, ISP, cell phone provider, and insurance companies in the last few years have been by typing back and forth on-line, probably with someone in a cheap labour country. Could even be deaf people. Seems like a great job for them.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2024, 08:34:08 pm
content: Quote from: coppice on October 15, 2024, 08:02:07 pmOf course; valid for the simple everyday cases. Exception:anyinteraction with Xafiniti Pensions is even worse than Virgin Media.But the exceptions are likely to be complex, difficultand important.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: December 04, 2024, 03:18:07 am
content: Maybe making memory safe C++ a better idea.https://safecpp.org/draft.html

author: tggzzz
author_rank: Super Contributor
timestamp: December 04, 2024, 09:30:07 am
content: Quote from: Doctorandus_P on December 04, 2024, 03:18:07 amThat's building an extention to an enormous edifice that is built on sand.C/C++ are 70s/80s languages which started by defining that any multithread/multicore functions were outside the scope of the language, and were a libraries' responsibility. That was fine in the 70s, but was already a pain point in the 90s.Rust and Go (and xC) are pleasingly simple languages (unlike C++) whichstartedby presuming they would run on modern multicore/multiprocessor operation.Finally people are realising that if C++ is the answer, then you asked the wrong question.Unfortunately it needs to be recognised that C/C++ will never go away, for the same reasons that COBOL has never gone away.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 04, 2024, 09:48:04 am
content: That's one reason Rust is a relatively bad answer to this as well. The only thing it kind of deals with is memory ownership. The rest of multiprocessing is still handled via libraries (and there are already several of them for the same job, which adds to the confusion).

author: DiTBho
author_rank: Super Contributor
timestamp: December 04, 2024, 10:33:17 am
content: Quote from: SiliconWizard on December 04, 2024, 09:48:04 amif we consider one of the worst RISC systems ever, a highly speculative R10K with more than 13 pages of "bad-side effect" due to its nature of being zero hardware support for anything, including cache coherence... then... RUST is even worse than C because you have twice the effort to write "workaround" patchs.Here the problem is clearly bad hw.The hw must offer support, it must not be the software that gets to the details of the cache, especially when there are DMA, external COPs and all the things that then are not clear how to model in the language constructs.(in myC, you can override monads, but it's still ugly)In effect what *we all do* is sweep the dust under the carpet. In a library, which then "fixes things" by hitting barriers on barriers written in inline-assembly.kind of Voodoo code.Now, doing this in RUST... is just much more more convoluted than in C

author: tggzzz
author_rank: Super Contributor
timestamp: December 04, 2024, 05:00:02 pm
content: Quote from: SiliconWizard on December 04, 2024, 09:48:04 amTrue enough: Rust isn't the solution to all problems. (Neither is Go, of course).But the memory ownership issue is a key problem with C/C++, spreading its tentacles into multithreading, multicore processors, multiprocessor computers. Rust has addressed (ho ho) those issues head-on from the beginning, whereas with C/C++ they are a bolt-on afterthought (yuk!) which plays badly with much existing code. Hence Rust is a significant and useful advance.A few years ago I decided to keep a weather eye on Rust and Go; they seemed to have advantages but it was unclear whether they would materialise in practice. History is littered with a succession of irrelevantly different "languages du jour" (e.g. C#, Delphi, Perl), and it is beneficial to ignore most of those.It is becoming clearer that Go and Rust will have a solid future, even if they aren't finished yet. As with all scientific/engineering revolutions, advances are made in a generational timeframe, as the current incumbents die.

author: DiTBho
author_rank: Super Contributor
timestamp: December 04, 2024, 08:16:52 pm
content: Quote from: tggzzz on December 04, 2024, 05:00:02 pmSo it seems. There are more and more tools written in GoText editors, versioning tools (lazy git), ...

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 04, 2024, 08:27:09 pm
content: I claim object access (range) validation and synchronization is a bigger problem than memory ownership, considering the number and severity of related problems. Locking schemes are difficult for us humans to design properly, so static analysis of those would be very important too. Coroutine and async support would be nice.I firmly believe these cannot be solved via increased abstraction, abstracting away the implementation and giving the developers tools toavoidthinking about these. An intuitive and effective way of annotating accesses, expressions, and arbitrary sections of code is needed. Function/member annotations like "must hold lockXwhen calling/accessing this" would be very useful, even if only heuristically verified by static code analysis.A particular detail that bugs me in C and C++ is that you designate anobjectatomic, instead of specific accesses to it. Just think about the locking nightmare if the compiler is allowed to reorder a pair of accesses to atomic objects, when such atomicity requires locks at the machine code level? Yeah, deadlocks galore.

author: tggzzz
author_rank: Super Contributor
timestamp: December 04, 2024, 09:00:59 pm
content: Quote from: nctnico on August 06, 2024, 08:37:31 amThat is already done, but naturally only to the extent it is possible. If it was possible, then that analysis would be useful in many areas, e.g. optimising compilation.The possibility of pointer aliasing kills many performance optimisations. The mitigation is compiler command line arguments to the effect that "I promise that my code and the code I call in other companies' libraries doesn't misbehave". Yeah right.Such compiler command line arguments affect the generated code as much as the source code, and ought to be part of the language definition.Meanwhile, back on planet Earth....

author: tggzzz
author_rank: Super Contributor
timestamp: December 04, 2024, 10:51:48 pm
content: Quote from: DiTBho on December 04, 2024, 08:16:52 pm... duplicates of C libraries such as coreutils,https://www.phoronix.com/news/Rust-Coreutils-uutils-0.0.28, opensslhttps://www.phoronix.com/news/Rustls-0.23.17-ReleasedetcIf you have foundation that is more theoretically sound than C's foundation, then more sound optimizations become possible.

author: tggzzz
author_rank: Super Contributor
timestamp: December 04, 2024, 11:05:04 pm
content: Quote from: Nominal Animal on December 04, 2024, 08:27:09 pmLocking is the low level primitive on which usable, composable high level abstractions can be built.QuoteAll that is still too low level.More useful system-level abstractions have been developed over the decades. Starting points are realtime design patterns, enterprise automation design patterns, and high performance computing design patterns.Naturally nothing will prevent inappropriate use of such design patterns, and it is still possible to get system level deadlock and livelock. But at least you have shifted the problems to a higher level, away from the implementation domain and towards the problem domain. one I've used repeatedly in various forms over the decades is the half-sync half-async patternhttps://www.dre.vanderbilt.edu/~schmidt/PDF/PLoP-95.pdf

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 04, 2024, 11:21:21 pm
content: Quote from: Nominal Animal on December 04, 2024, 08:27:09 pmAgreed.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 12:08:48 am
content: Quote from: SiliconWizard on December 04, 2024, 11:21:21 pmA lot of system design and programming is bridging the gap between the processor level abstractions (ISA, caches, memory consistency, multicores) and the problem domain level abstractions. Usually there are several levels of abstractions (programming languages, libraries, design patterns) between the two ends. Finding a single person that can think at all levels is, um, challenging.Anything that makes it easier to create executables that are structured so that a problem domain specialist can understand and reason about the code is very valuable.Unfortunately too often abstractions are layered on each other without understanding the underlying abstractions. If you doubt that, start by considering the numbers of synchronous and asynchronous protocols between, say, a network PHY and an enterprise application.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 05, 2024, 05:03:25 am
content: Quote from: tggzzz on December 05, 2024, 12:08:48 amMy point exactly.Added abstractionsare not the correct answer. Yet, that is exactly what we are doing.As you know, I personally prefer using C for systems and library programming, and switch to interpreted high-level languages like Python for the UI. Not to manage abstractions per se, but to solve the particular problems at the same level of abstraction, simplifying the interdependencies.The recent storm in a teacup about Rust and the Linux kernel internal interfaces (lack of internal APIs, and subsystem maintainers being unwilling to commit to maintaining them for Rust developers), and the number of abstractions and additions and annotations Rust requires for interoperability with foreign machine code, makes me believe it is not the correct direction either for low-level code. I see it falling to the same trap C++ did, trying to be everything for everyone, while still trying to discover what it should be and might be, and growing all sorts of warts extending and ballooning itself as a result.I suspect that to properly solve the human capability versus abstraction issues, we'll need different programming languages at different complexity levels. Even in Python, you already have three different string formatting approaches, two completely different ones; just like in PHP, when they added OOP on top you ended up with a doubled standard library, with two or more approaches to solving every problem. In theory, that sounds like only a good thing, but when you mix in humans with our limited capabilites, it turns out that simplified tools work better. Which, in turn, leads us back to Unix philosophy: simple, modular tools that you connect together, instead of All-Encompassing Frameworks to Solve All Problems Everywhere.In that light, the DARPA suggestion is similar to the political revolutions, where the former oppressed become the new rulers, and former rulers the new oppressed, but nothing actually changes. I guess it is a good gig if you get paid for turning the wheel in place, though. Me, I just want to solve problems and make better stuff, not tell others what to do and how (unless they explicitly ask).

author: magic
author_rank: Super Contributor
timestamp: December 05, 2024, 09:50:22 am
content: Quote from: Nominal Animal on December 05, 2024, 05:03:25 amI also find this fad annoying, and I hope that it will ultimately lead to Yet One More Programming Language, this time designed for close interoperability with C and for converting existing C codebases rather than rewriting them from scratch or wrapping in pointless glue layers. Obvious crippling limitations of this month's Safe Language Of The Month are lack of type erasure to naturally cover the countless uses of void* out there and opaque vtables (like in C++) which can't straightforwardly interoperate with equally countless object oriented designs in C.For low level use case "tagged unions" and "traits" should be simple annotations to raw C-style structures which constrain their semantics, giving you control over memory layout for interoperability with other languages, with hardware, with anything that isn't Safe Language Of the Month which you may need to work with.Safe Language Of The Month was designed by application developers to replace C++ and I suppose it has a good chance in this space, but the attempts at pushing it into traditional C areas is just that: annoying. Hopefully YOMPL will learn from those mistakes and offer an actual viable migration path from C, and there is certainly a growing demand for that.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 10:17:26 am
content: I've omitted points that I agree with.Quote from: Nominal Animal on December 05, 2024, 05:03:25 amSimplifying the interdependencies is always important, but I'm not sure I'd put it in terms of "... same level of abstraction".Some abstractions are impossible to sensibly hide, and trying to do so leads to subtle errors. A classic example is distributed computing, where too many libraries try to pretend thathttps://en.wikipedia.org/wiki/Fallacies_of_distributed_computingdon't exist. Many times low-level failures can only be correctly dealt with at the top level.QuoteThat is a serious and important impedence mismatch, but I don't agree with your conclusion. That impedance mismatch is largely a culture clash, and with the technology clash being the less important aspect.The counter example to your conclusion will come when Rust becomes sufficiently effective to implement a kernel. Redoxhttps://www.redox-os.org/is a good start. Practically it isn't there yet, but I haven't seen any theoretical show stoppers.QuoteC with classesC++ has always been a distasteful mess, where the creators were too ignorant to plant a pole in the ground saying "this is a good set of concepts thathave been shownto play well together". Instead they punted the problems to their users, hoping they would sort them out (they didn't).Unfortunately in the 1990s C also fell into the trap of trying to be both a low level and an application level language. Either choice would have been OK, but the result is a mess. Hence we have Java and Python taking over the application domains, and C becoming too complex for low level stuff.QuoteI 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.QuoteEvery {technical, legal, corporate, political} empire starts small, then accretes crap, and that forms the basis for their demise. They rot from within.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 10:35:31 am
content: Quote from: magic on December 05, 2024, 09:50:22 amAvoiding the variant-language-of-the-month is key professional skill, but it is also necessary to encourage advances and then to spot and use the benefits. Such advances and benefits seem to happen once a decade or so, and take a generation to become understood and accepted.Any language with untypedmemoryis an architectual sand pit. It is much safer and more expandable to have untypedvariablesoperating on typed memory. Even better to have typed variables and typed memory; the former enables better/faster source codeandtools, the latter enables safety/debugging.C and C++, of course, have untyped memory - which causes endless problems.I'd much rather concentrate my efforts on discovering and ameliorating the problemsinherentin the application domain. I dislike tools that add their own problems, and prefer tools that help me solve application domain problems.

author: JPortici
author_rank: Super Contributor
timestamp: December 05, 2024, 11:24:32 am
content: Quote from: tggzzz on December 05, 2024, 10:17:26 amHaving an actual specification and a compiler conforming to said also would help, same for embedded, or we are all going to have the same exact arguments we see about C (see for example the code-size limited thread in the microcontroller section) all over again, but with a more toxic community behind them.

author: madires
author_rank: Super Contributor
timestamp: December 05, 2024, 11:44:04 am
content: I wonder if it is actually feasible to turn C code into Rust automatically. Or would it make more sense to fix the memory management bugs and security issues in the old C code? Using Rust (or whatever) for new projects could be a reasonable approach to tackle the typical sloppiness of C developers regarding memory management. It would decrease the attack surface to some extend. However, there are many things more that can be screwed up. If a developer can't manage memory, how likely will he also fail to validate some input? I think, teaching developers to write good and secure code is the best way to go forward. The programming language isn't that important, but how it is used matters.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 11:56:27 am
content: Quote from: madires on December 05, 2024, 11:44:04 amIt is feasible provided either you want to duplicate the bugs or the tool automatically determines the intended operation and implements that.Oh.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 12:35:29 pm
content: My RSS feed has just thrown up this example of abstraction leakage, plus how C/C++ compiler command line arguments are in effect part of the language (ugh).https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level

author: coppice
author_rank: Super Contributor
timestamp: December 05, 2024, 03:31:54 pm
content: Quote from: tggzzz on December 05, 2024, 12:35:29 pmThose CPUID bits are a serious PITA. What started as a nice "I can detect how advanced the machine is, and see which tricks will work" feature has become a free for all "let's fragment the fragments of the fragments" kind of thing. What brain dead idiot thought making 1000 different configurations of what an x86_64 machine might be would encourage programmer to get the best out of them?

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 05:01:12 pm
content: Quote from: coppice on December 05, 2024, 03:31:54 pmIntel and AMD, of courseWith the exception of backwards compatibility, to them software is an "externality" - i.e. somebody else's problem.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 05, 2024, 09:31:23 pm
content: Quote from: tggzzz on December 05, 2024, 10:17:26 amWhat I mean by that, is that I want a low level imperative language with minimal abstractions to implement low level library, number crunching, and data processing libraries and system services. For graphical UIs, I want an event driven language with high abstractions (but good interface to low level machine code, preferably with minimal added machine code).I do not want a single language that can do both, because that means others modifying or writing more code have a high chance of using the wrong paradigm. (And that is assumingIget it right myself, which is definitely not guaranteed!)Quote from: tggzzz on December 05, 2024, 10:17:26 amAh yes, now I see your point. I definitely agree, because one of my buttons is how most current distributed molecular dynamics simulators compute then communicate, wasting a lot of potential CPU time, rather than communicate while computing, simply because their designers didn't want the added complexity of thinking how to do it right (which is spatial subdivision of the simulated volume, and computing these in a specific order that allows the shared regions to be communicated to neighboring nodes while computing the non-shared regions).Quote from: tggzzz on December 05, 2024, 10:17:26 amPerhaps; I am often wrong. In that case, however, I don't see how a cultural change will solve the added workload of maintaining the C-Rust interfaces required for Rust. My opinion is also coloured by observing how much abstractions and changes to Rust itself I see discussed at LKML, for achieving an usable C-Rust interface.Quote from: tggzzz on December 05, 2024, 10:17:26 amNo, because you can write a kernel in any sufficiently low-level programming language. The counter example will be when you have a functional kernel written in one of these new languages with core functionality easier to manage –– considering themodification ratein the Linux kernel, i.e. refactoring and changes, not just bugfixes and maintenance against bitrot –– and preferably with lower bug density, than the Linux kernel.That, I believe, is the true test by fire for a low level language. For a kernel, it will also need to have high enough performance, which in practice means low cost of kernel calls, high-bandwidth low-latency userspace - kernel data transfers, regardless of kernel design (monolithic or microkernel), but the main weight, in my opinion, should be how well human users can use it.(I do not believe in using theaveragehuman developer as a metric, though. Any tool can be misused; see real world issues with firearms. Rather, I want to focus on the best existing examples, best open source code implemented with finite resources, to evaluate the language used.)Quote from: tggzzz on December 05, 2024, 10:17:26 amYep. I can do a graphical UI in C using Gtk+, and it isn't horrible, but one has to be quite careful to avoid bugs and issues.Combining Gtk+ UI and low level data processing or computing, I personally need to "switch" between paradigms or complexity levels or whatever you want to call them, and treat the two as if I were using different programming languages: I need to think in different patterns. When you add to that the communication needed between the two, it just isn't worth it for anything except basic tools and examples (of what is possible, to motivate learners).Quote from: tggzzz on December 05, 2024, 10:17:26 amYep, exactly: interoperability, not encompassing frameworks.I do not particularlylikePython either. I use it because it interfaces to low-level code so easily, and allows one to create event-driven graphical user interfaces at the same level that you can get humans to think of. (My examples of Python + Qt5, using Qt Designer -edited XML .ui files, with events mapped to systematically named methods in your main window class implementation, are exactly that: no matter where or what it is, you need to give a widget a name, and look up the name of the signal/event generated from the documentation, and that will tell you the name of the method you need to implement. Plus, it allows UI editing by modifying the XML –– even multiple UIs one can choose from at run time ––; and UI behaviour by modifying the interpreted human-readable code.)I do believe it was a masterstroke from Guido van Rossum to ensure C interoperability. Without that, I do not believe Python would be as popular as it is now. Interoperability with any shimming implemented in the high-level language side is possibly Python's strongest point.Quote from: tggzzz on December 05, 2024, 10:17:26 amCompetition that drives crap removal is the only cure I know.I do not believe in revolutions, because they just tend to turn the pyramid upside down, but not change its composition otherwise; and very soon it will be indistinguishable from the previous one. Same with enemies, as we see in the world right now: all countries seem to be striving towards 1984-style dystopian eusocial systems, pointing out the flaws in others while blithely ignoring the same ones in themselves.Gradual changes seem to work much better.It is also the reason why I don't dabble with creating my own "better than C" low-level programming language. C has a track record and untold hours of development by brains better than mine. What I do as a hobby, is investigate the free-standing environment; replacing the (optional!) C Standard Library with something better, because that is compatible/interoperates with everything fluently. It is by no means perfect, and I do wish I could change specific things even in C (namely, swap pointers and arrays, allowing compile time bounds checks over function calls), but it is better than any "revolution" I could instigate (programming language I could design).None of this is to say I won't use Rust myself! I wrote all this because I wanted to point out how silly theideaof automatically converting code from one paradigm and language to another is, and how silly, in light of history and all we know, the idea of Rust becoming the new C is. Rust should be Rust, and evolve to fit whatever niche it finds, and not try to be everything for everyone because that has been tried several times and has always failed –– including C!What that niche will be, I do not know, but seeing how I happily use even PHP in specific circumstances (webhotels with limited server-side language support), I fully expect myself to be happily using Rust also at some point. (Thus far, I've been looking at how its developers approach problem-solving, and I'm not sure I like it yet: it seems tooabstractfor my needs at this point, too focused on achieving their goals, and not focused enough on actual results and behaviour of the result. Like academics discussing mathematics from the point of proofs, when all I'm interested in is using it as a tool to solve problems. It is my impression only, though.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 05, 2024, 10:51:18 pm
content: 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.There is just one thing, for which I have (probably like you do) a few answers, but nothing that I find completely rational: outside of niche fields, nobody uses it.I admit I don't use it either. Yes, I have a few reasons, again, but they aren't all completely reasonable. One is that 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.Is the compiler thing the only reason we don't use it though? Not so sure.Syntax? Who cares, I personally don't mind and find it a lot more readable than Rust. It probably icks the Javascript nerds though.Although you can use pretty lean runtimes for embedded dev, it yields "heavier" compiled code on average, so for very small targets, it may not be the best candidate. But otherwise?It kind of puzzles me. Again, I'm questioning myself too, as I don't use it either, although that's something I've been planning on doing for years now.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 11:00:53 pm
content: Quote from: Nominal Animal on December 05, 2024, 09:31:23 pmA cultural change is indeed unlikely to be sufficient in this case. I suspect it is necessary.Rust and its community is not "innocent" in this area - and that is likely to continue as long as Rust is changing.QuoteI have this fantasy that if there is a good language, concept abstraction, coherence and coupling, then any single code mutation will have only local effects. That makes life much easier!I like to think that a decent language will circumvent some problems, making them a non-issue. That kind of thing does occasionally happen.It remains to be seen the extent to which Rust and Go will aid those aspirations.QuoteAre you aware of The Mill Processor's and toolchain's architectural concepts? They are radically different to today's processors with many performance improvements. While their starting inspiration is the commercially successful Burroughs Algol systems, a specific principal objective is to be able to run unmodified C code exceptionally fast.Shame none exist, due to the x86 inertia. I suspect some of their heavily-patented ideas will be found in future processors.QuoteI 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.QuoteSuch crap removal is thwarted by the requirement for backward compatibility. The latest Windows still contains some GUI dialogs that are unchanged from Win 3.1; IIRC the ODBC config dialog looks positively primevalhttps://www.reddit.com/r/Windows10/comments/o1x183/the_famous_windows_31_dialogue_is_again_in/#lightboxBackwards 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.QuoteWe need something to consign C/C++ to being equivalent to COBOL.So far Rust is the best candidate for the mid-to-low level use cases, but time will tell. C/C++ has already lost the mind set for high level use case applications, with new applications implemented in Java, Python, Go, plus other more domain-specific languages.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2024, 11:08:43 pm
content: Quote from: SiliconWizard on December 05, 2024, 10:51:18 pmPlus the SPARK Ada variant has some very interesting properties. Proponents say that if your program compiles, then it will do what you intend and wantShame too few people care about correctness.QuoteI 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)

author: DiTBho
author_rank: Super Contributor
timestamp: December 05, 2024, 11:14:52 pm
content: Quote from: SiliconWizard on December 05, 2024, 10:51:18 pm{ 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.

author: DiTBho
author_rank: Super Contributor
timestamp: December 05, 2024, 11:25:58 pm
content: Quote from: tggzzz on December 05, 2024, 11:08:43 pmHere I amI 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!

author: DiTBho
author_rank: Super Contributor
timestamp: December 06, 2024, 12:00:24 am
content: Quote from: SiliconWizard on December 05, 2024, 10:51:18 pm... 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

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 12:51:13 am
content: Quote from: DiTBho on December 05, 2024, 11:25:58 pmI'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)

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 06, 2024, 12:53:42 am
content: Quote from: tggzzz on December 05, 2024, 11:00:53 pmSomewhat – 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 findextremelyinteresting. 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.Quote from: tggzzz on December 05, 2024, 11:00:53 pmAh; "Language featuresX 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).Quote from: tggzzz on December 05, 2024, 11:00:53 pmTrue, 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.Quote from: DiTBho on December 06, 2024, 12:00:24 amA major reason why I don'twantto design my own programming language is that IknowI'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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 12:58:46 am
content: Quote from: DiTBho on December 06, 2024, 12:00:24 amWrong. 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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 01:08:23 am
content: Quote from: Nominal Animal on December 06, 2024, 12:53:42 amWell, .... yes.I've come to regard such wading as the price for keeping technically up to date. Having to do it ensures youactivelyconsider whether the next toy is merely new and shiny, or whether it actually allows you to do things you couldn't do before.QuoteIt 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2024, 02:07:53 am
content: Quote from: Nominal Animal on December 06, 2024, 12:53:42 amThat'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.

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 02:49:49 am
content: Quote from: tggzzz on December 06, 2024, 12:58:46 amInteresting. Azul came up in two threads on the same day, and I hadn't heard their name in a decade.

author: DiTBho
author_rank: Super Contributor
timestamp: December 06, 2024, 07:48:56 am
content: Quote from: tggzzz on December 06, 2024, 12:51:13 amtalking about obessions, that's #2 in the list

author: DiTBho
author_rank: Super Contributor
timestamp: December 06, 2024, 08:56:14 am
content: Quote from: tggzzz on December 06, 2024, 12:58:46 amumm, 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

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 10:25:56 am
content: Quote from: DiTBho on December 06, 2024, 08:56:14 amI 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.

author: Simmed
author_rank: Frequent Contributor
timestamp: December 06, 2024, 10:31:00 am
content: hahais this 1 of those things that get rounded up then everybody gets forced to pay subscription ?

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 11:02:59 am
content: Quote from: coppice on December 06, 2024, 02:49:49 amI 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.Skimminghttps://www.azul.com/wp-content/uploads/azul-and-gridgain-benchmarks-presentation-1.pdfindicates 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

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 11:11:44 am
content: Quote from: tggzzz on December 06, 2024, 11:02:59 amI believe Azul was started by some of the key Java people from Sun, but that was well before Oracle bought Sun.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 11:16:55 am
content: Quote from: DiTBho on December 06, 2024, 08:56:14 amSmalltalk 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/Rekursivreference 3 is also enlightening. I didn't know any of it, but it doesn't conflict with the little I knew.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 11:20:14 am
content: Quote from: Simmed on December 06, 2024, 10:31:00 amCare 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.

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 11:32:25 am
content: Quote from: tggzzz on December 06, 2024, 11:16:55 am"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?

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 11:41:00 am
content: Quote from: coppice on December 06, 2024, 11:32:25 amIt 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.

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 11:45:45 am
content: Quote from: tggzzz on December 06, 2024, 11:41:00 amARM 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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 02:55:35 pm
content: Quote from: coppice on December 06, 2024, 11:45:45 amThe 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.

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 04:43:37 pm
content: Quote from: tggzzz on December 06, 2024, 02:55:35 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 05:06:00 pm
content: Quote from: coppice on December 06, 2024, 04:43:37 pmThere 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2024, 08:51:14 pm
content: Quote from: tggzzz on December 05, 2024, 11:08:43 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 09:47:02 pm
content: Ada was tainted by being European, DoD, and having normally expensive tools.The main reason C and Unix became dominant was that it was given away free to universities, so students became familiar with it.As usual, technical merit is only one point, and not the most important point.The first version of SPARK was produced at my alma mater, by one of my lecturers, Bernard Carre. Even in 77 he was interested in program correctness, and introduced us to the concepts of assertions and contracrs.

author: magic
author_rank: Super Contributor
timestamp: December 06, 2024, 09:54:52 pm
content: Popularity with students and hobbyists is the key.Do you realize that Fortran still exists and apparently got a minor spec revision last year?I didn't know about the latter until a minute ago, but I know about the former because I briefly worked with Fortran some decade ago and I'm sure this project still exist.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 10:09:27 pm
content: Fortran is unparalleled for numerical analysis, and is still important for HPC.It has many numerical libraries that have been designed by mathematicians and competent engineers that know their job. If only that was true of all libraries.

author: coppice
author_rank: Super Contributor
timestamp: December 06, 2024, 10:50:39 pm
content: A lot of the HPC code running on large Linux clusters is written in Fortran. Partly for historical reasons, and partly because HPC type code runs fast without much optimisation effort. Updates have done a lot to make the new code look less like spaghetti, so its a much better language to write in than it used to be.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2024, 11:44:38 pm
content: Quote from: coppice on December 06, 2024, 10:50:39 pmC has many features that mean the compiler cannot output optimal code. Command line arguments can be used to tell the compiler "I promise this code won't do X, honestly", but they aren't as good as a decent language that doesn't have pessimising features.Two of the most obvious pessimising features are pointer aliasing, and the heavy use of pointer themselves.Fortran is fundamentally array based without aliasing, and that "plays nicely" with caches and prefetching. Pointers bust both, since the dereference address is unpredictable.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 07, 2024, 12:06:20 am
content: Quote from: SiliconWizard on December 06, 2024, 08:51:14 pmTo me, the biggest thing is GNAT being the only open source compiler, and a lot of people saying the commercial ones are way better.The first programming languages I learned, in order, were BASIC, 6502 assembly, and (Borland Turbo) Pascal, so I don't mind the language itself at all; it's quite comfy to me. (Then again, when you're happy to write code in more than a dozen different programming languages, you tend to not care that much about syntax nitpicks. Perl is the only one I avoid, and that just because I have kinda-sorta "PTSD" from having to work on a horrible code base written by people I like: talk about emotional and cognitive dissonance!)I haven't looked at AdaCore embedded stuff, but I once spent quite some time to get a distributed HPC simulator written in GNU Fortran (95/2003) to read and write non-native binary files, and really missed hardware-defined types. At some point I readThe Implementation of Ada 2005 Interface Types in the GNAT Compiler(PDF at AdaCore), which discusses the changes they did to GNAT type implementation to simplify interfacing to C++ code, which indicated to me that such low-level interfacing to native code is nontrivial in Ada, and likely requires native/machine code shim or interface layers –– just like Fortran in practice. So, I basically put Ada mentally in the same category of domain-specific languages. (Fortran is still heavily used in numerical computation, for mostly non-technical reasons; I know Ada has several niches especially in aviation and other safety-critical systems.)Now, I'm fully aware that most of my assessment of Ada is likely wrong. Because of the single open source implementation, I haven't even tried to correct them. I just don't like being dependent on a single vendor, or dependencies on singular things in general: I need options.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: December 07, 2024, 12:49:56 am
content: Quote from: tggzzz on December 05, 2024, 10:17:26 amThis I think is the downfall of all of the one size fits all solutions. Be it Ada or Rust or whatever.I started on Algol, then cycled through FORTRAN, Basic, Pascal, Visual Basic and finally in the last decade have been forced into C and Python. Developed an ability to read, but not write several other languages along the way. I chose not to make software the core of my career back in university when I realized that I didn't want to be fighting these battles every day of my working life. But working in the industry you can't avoid contact with it, and I lived through the forced use of Ada in US DoD projects in the 80s and 90s, have watched coding teams that believe a GUI is the right answer for every kind of software, right down to the safety timer in a coffee maker, and so on.There seems to be a great lack of understanding by the designers of languages/compilers of the actual applications that their gems will be used to implement. Many marvel at the survival of FORTRAN. Some ascribe it to the well tuned math libraries that are available. I agree that is part of it. But I also believe that a hidden element associated with those libraries is that FORTRAN is designed with a native complex number type. The mathematics of engineering and physics rely heavily on complex arithmetic and huge fractions of the code depend on this. I am not aware of any other language that address this directly. Several including C++ and Ada do allow you to define your own data types and use operator overloading to attempt the same thing. But these are local solutions, the software written under them is not portable. There is no reason that complex could not be a native type in other languages, but the designers of most languages just don't see the need.Similar problems beset other languages trying to be all things to all people.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 07, 2024, 02:29:44 am
content: Quote from: CatalinaWOW on December 07, 2024, 12:49:56 amC has three (complex float,complex double, andcomplex long double, although the latter two usually have the same range and precision), exposed by including<complex.h>, in the standard C math library.Addition, subtraction, multiplication, and division using these types do the corresponding complex arithmetic operations. For standard library math functions, the function names are prefixed withc. For standard C library functions, seeman 7 complex.With respect to complex number support in the language/standard library itself, C and Fortran do not have significant differences. (And I have done HPC software development in both languages, mostly using MPI for distributed parallel processing.)For further details in complex arithmetic support, see ISO C99/C11/C17/C23 standard, chapter7.3 Complex Arithmetic<complex.h>.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: December 07, 2024, 03:02:16 am
content: Apparently the compilers of C that I have seen don't implement the full language. I haven't looked at gcc.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 07, 2024, 04:02:42 am
content: Quote from: CatalinaWOW on December 07, 2024, 03:02:16 amIt is an optional feature. If the preprocessor macro__STDC_NO_COMPLEX__is defined and equals to1, then the C compiler and/or standard C library doesnotsupport complex types. There is also no requirement to implement<complex.h>for freestanding environments, for example embedded or kernel development. You only see it used in fully featured, hosted environments –– but if the target hardware supports single- and double-precision hardware floating point, you can expect these complex types to be available.The native C complex types are also supported by the common math libraries, including FFTW.AMD Optimizing C Compiler, Clang, GCC, IAR, Intel oneAPI and classic C compilers, Open64, Pelles C, and Portland Group C Compiler do support complex types. (Of course, they also require the target standard C library to support the complex types, because the compiler only provides support for the base complex arithmetic.)Of these, I've used GCC, Intel, Open64, and PGI on x86 and x86-64 (Linux, with glibc as standard C library) for complex number stuff in C, when I did some sonification research. I just checked my local installation of Clang 10, and it too supports complex types on x86-64 using glibc and newlibc.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 07, 2024, 04:08:39 am
content: C99-compliant compilers should have reasonable support for complex numbers. GCC sure does.I don't use them when I need performance though. The reason is that GCC has apparently favored correctness over performance, more so than with basic FP operations. Yes, even with -ffast-math. You'll usually get much better performance implementing the complex operations yourself. This point may change as GCC evolves, though, so YMMV. And yes, there are potential pitfalls when naively implementing complex operations "by hand" (rounding and precision issues), so I'm not saying that what GCC does is wrong. Just mentioning that sometimes you need extra performance at the expense of those edge cases, and as I mentioned, last I tried, even with the '-ffast-math' option, GCC would generate suboptimal (in terms of performance, again) code for complex operations - at least for multiply, divide.OTOH, if you need the compiler to take care of those precision issues for you, do use the C complex types instead of hand-implementing complex numbers, it'll save you a lot of time.Commercial C compilers for embedded targets are a lot less likely to include support for complex numbers, so wouldn't be surprised there. As to MS C compilers, it took them so much time (apparently completely on purpose) to have anything C99-compliant than here again, no surprise. They have caught up though, I believe, and you now have reasonably good C11 compliance. My understanding is that MS hasn't cared for C for over 25 years and did focus on C++. Of course they still needed C for the Windows kernel and drivers, but they would only require C89 and they have never cared about using more recent versions of the standard.Haven't used the Intel C compiler (which was very good in terms of performance for x86 targets) in a good while, but I'm pretty sure it has been supporting complex numbers for a long time.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 07, 2024, 04:24:18 am
content: Quote from: Nominal Animal on December 07, 2024, 12:06:20 amYes, that was also one of my points, the tooling. But at least there are many options, including an open-source one. Sure most others (all others?) are commercial proprietary stuff. This single-option problem also bothers me in theory, but OTOH this is the case for most other newer languages, like Rust, and nobody seems to care (and I find it even more concerning as there isn't any standard nor even any formal spec yet from which others could at least develop their own compiler).As I said, yep, that's also what I've constantly heard regarding GNAT being poor compared to the commercial compilers, but I don't know if it holds true. When was the last time pro users of Ada did use a recent version of GNAT on real projects and found it problematic? I don't know. I suspect that doesn't happen very often and suspect most opinions are built on prejudice.But as I mentioned in another post, the ecosystem is a real culprit. Good luck finding bindings for all the libraries you routinely use, GUI toolkits, and so on. I know there are Gtk bindings for Ada, but for Qt, I don't know. Ada (at least via GNAT) has relatively good support for interfacing with C. But with C++? Not so sure. Then again, who wants to *implement* interfacing with C++, talk about a nightmare.Been meaning to invest some time seeing how I could use it for embedded dev, but thing is, I must admit that C still fits the bill pretty well and I am unsure if this time would be well invested. What I dearly miss in C are modules and some generic programming - I do use macros for that, but that's not the most elegant thing you can think of.

author: tggzzz
author_rank: Super Contributor
timestamp: December 07, 2024, 10:32:19 am
content: Quote from: CatalinaWOW on December 07, 2024, 03:02:16 amWell, there's a surprise.FirstlywhichC or C++?Secondly a couple of decades ago I remember seeing a press release triumphantly proclaiming their compiler was the first to support the full language (C or C++, can't remember). That was6 (six) years after the relevant standard was published.I won't bother to note that in the late 90s (and presumably later) compiler writers were having considerable difficulties understanding the C/C++ standards w.r.t. how all the different bits interacted. Unsurprisingly different compilers had different understandings. If you are really interested in deep language infelicities, search out Nick MacLaren's posts on usenet. Nick MacLaren worked at the University of Cambridge, supporting people working on bleeding edge HPC applications in many languages. Heknewwhere the skeletons were buried, and exhumed them when beneficial.Here's one example:https://www.open-std.org/jtc1/sc22/wg14/9350Notice the provenance.A few choice snippets, out of context...QuoteOK; I lied: I did note it. So sue me

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 07, 2024, 11:38:40 am
content: Quote from: tggzzz on December 07, 2024, 10:32:19 amThat's why C11 went completely off the rockers, adding things only implemented by a single vendor (who didn't even have a native C compiler, only a C++ one that supported a subset of C).C99 and C23 standardized things that have been found to work in practice first. That is how it should be for a language with sufficient history: you don't develop the standard text first, then try to implement it; you implement various things, let them compete, and extend the language when a consensus appears or users agree.In other words, if you try to further develop a language with as wide existing code base and history as C standard-first, hoping/demanding compiler implementers will follow it, you're doing it wrong. Only if you extend it carefully, with implementations tested and verified to work for the vast majority of the user base, makes it sense to codify it into the standard.It is different when the language itself is still being developed, still looking for its niche. Then, it does need strict focus and careful planning, so that it does not fall into the everything-for-everyone trap. White papers and exact specifications for languages are excellent. But there comes a point when any radical change should be ruled out (and instead create a new language, not just a new version), and further development of the language limited to extensions, practice first, what users find most useful, without breaking the existing code base. Consider Python 2 vs 3 as an example, and all the pain and extra work that created.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 07, 2024, 12:04:57 pm
content: Quote from: Nominal Animal on December 07, 2024, 11:38:40 amFor the same reason, complaining aboutexistence of extensions, like often happens in recurring train wreck threads on the microcontroller subforum, is ridiculous*. It is important for standard to allow extensions. Only that enables progressive innovation. If we cannot have extensions, this only leaves three choices:1) proactive standardization of features committees think are important, in ways committees think are correct2) inventing completely new languages from scratch, or3) stopping all innovation and advances in languageswhich are all much more problematic than the simple option of using extensions to drive solutions to real needs programmers see, and codifying those that stand the test of time to standards, which leads to a combination of finding local maximum while still producing a stable, well-understood, standardized language.*) it is extremely funny though that the same people for whom allowing extensions and leaving some details undefined is poison, do not see any problem in using languages withno stable specifications at all.

author: tggzzz
author_rank: Super Contributor
timestamp: December 07, 2024, 01:10:09 pm
content: Quote from: Nominal Animal on December 07, 2024, 11:38:40 amFrom theemboldenedstatement, can we presume that C and C++ arenot"still being developed"?As for "going off the rockers", I lost interest in the languages during the endless (i.e. years) long discussions in the 90s as to whether or not to allow "casting away constness". There are good arguments for both.I believe it has been decided that you can "cast away constness". That allows optimisations which rely on const behaviour (especially valuable in performance critical libraries), but also allows other code that silently violates the guarantees, e.g. by users of the library.Castles built on sand. No wonder people are pushing for better alternatives.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 08, 2024, 01:29:06 am
content: Quote from: tggzzz on December 07, 2024, 01:10:09 pmHuman languages are vague, and I'm not very proficient in English phraseology. Choosing proper words with the correct associations ishard.I meant "still being developed" in the sense of not beingfeature-completeyet; being still in the development stage where changes to planned/designed features are still considered generally acceptable.After a language is feature-complete, you stopchangingthings, and instead onlyextendandincrease specificity. I believe those extensions should be tried in practice first, preferably more than one implementation, before codified in a new version of the standard. Changes are reasonable only when they no longer affect widely available hardware; when they do not break existing code using widely available hardware.For example, C could easily "fix" right-shifting negative values for two's complement types (intN_t,int_fastN_t,int_leastN_t) by standardizing it the way all compilers that don't produce garbage do it (which is right shifting the storage bit pattern, duplicating the sign bit).Thisis the right approach, because it has been shown in practice to work –– C99, C23, Fortran 95, Fortran 2003 for example.In this sense, C is already feature-complete. Changes to the standard must not break existing code. Changes that codify implementation defined behaviour or even undefined behaviour, to how all "sane" compilers already implement them, or when one single behaviour makes sense and is useful on current hardware, are good. New keywords likeconstexpr(C23) fix historical mistakes/issues (constin particular), but do not break existing code; they are more like bugfixes that have been shown to be useful and acceptable to the vast majority of C users.(constexpris a bit special, because while it hasn't been implemented by anyCcompiler before inclusion in the standard, it was implemented in C++ in basically all compiler families that support both C and C++. So, while it doesn't fit into the literal "implemented by C compilers first" category and is more like an import from C++, the two languages are close enough for this kind of cross-importation to make sense. Another example is the C++11 memory model, and how GCC and Clang imported that forC atomic built-ins, as thesync built-insIntel designed for Itanium that GCC supported just didn't cut the mustard on other architectures.)I knew when I posted my previous post I wasn't expressing "still being developed" correctly, and am not sure I expressed it here much better. When Python 2 to 3 was done, I considered Python 2 to be feature-complete, and the change too great for a simple new version, and would rather have seen a new language been created (say,Pythoff). In comparison, I see the changes from ISO C90 to C99, and from C99 to C23 (regardless of whether you consider C11 and/or C17 in between), as integrating the changes existing compilers had basically already implemented and agreed to. (Notall, of course, but sufficient majority to show that they are preferable to users. And including the cross-importation from C++, which for the related features is close enough to C, for that to make sense as "prior art" if you will.)

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 08, 2024, 02:01:59 am
content: What a lot of people do not seem to realize, is how tiny and simple the freestanding C language itself is. The vast majority of the C standard is about the Standard C Library, which is not available in freestanding C (whichisa reasonably well defined part of the ISO C standards).Thatcompactness is what a new low-level language should target. Ignore the entire standard library until well after the language itself has stabilized, and focus on low-level compatibility with existing binary ABIs (including syscall interfaces when running under a fully featured OS) and microcontroller and embedded environments. ELF object file format has shown its superiority compared to others, so integrate its features (at least the concept of being able to name an arbitrary linkersectionfor each function/variable/object).I personally don't like the abstract machine concept. The current one used in the C standard is too simple to reflect current hardware. Any abstract machine model will similarly lag behind, because hardware development has been shown to well outpace programming language development. The main problem in low-level language definition approaches seems to be operation ordering, or rather, specifying the ordering of observable side effects. The C++11 memory model semantics shows that such ordering is not unique from a validity point of view: each side effect has a range where it is valid, when the program works as intended in all situations (assuming correctly written code here). The abstract machine model the C standard uses specifies a single step for each observable effect, which makes designing and implementing optimization strategies quite difficult.Defining the language based on the observable side effects, while leaving maximum control of their ordering to the code written in that language, is what I'd want. As of right now, I have no idea how that could be done, or whether it is even possible in the first place.

author: tggzzz
author_rank: Super Contributor
timestamp: December 08, 2024, 12:00:45 pm
content: Quote from: Nominal Animal on December 08, 2024, 01:29:06 amJust so. In addition I was being too terse. Apologies.I think strict focus and careful planning is required at all stages of language design and extension/development.The "cast away constness" dichotomy is real and important, and indicates that the language's focus has been lost and is being extended beyond reason.Analogy: construction scaffolding used to be made from wood, and bamboo is still used in developing countries. Just because it can and is used for large constructions, doesn't mean that it wouldn't be better to use steel scaffolding. Large C programs are like this:

author: coppice
author_rank: Super Contributor
timestamp: December 08, 2024, 04:06:29 pm
content: Quote from: tggzzz on December 08, 2024, 12:00:45 pmThat's a bad analogy. Wooden scaffold is a bit iffy, but developed places, like Hong Kong, still use bamboo almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so light and easy to handle. If you actually get the job done, and the scaffold removed before materials start to degrade, its fine. China banned bamboo in favour of steel, largely to divert attention for the kind of ham fisted, unskilled people who were doing the work, and how long many half completed structures remained like that with a scaffold in place until the materials degraded.

author: tggzzz
author_rank: Super Contributor
timestamp: December 08, 2024, 04:16:40 pm
content: Quote from: coppice on December 08, 2024, 04:06:29 pmAnalogies arealwaysdangerous. People concentrate on the analogy rather than the original topic.BASIC programs are a bit iffy, but developed places, like Hong Kong, still use BASIC almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so quick and simple to use. If you actually get the job done, and the program does its job before maintenance start to degrade it, its fine.

author: DiTBho
author_rank: Super Contributor
timestamp: December 08, 2024, 06:26:07 pm
content: Quote from: Nominal Animal on December 08, 2024, 01:29:06 ammyC refuses to compile and throws an error for any attempt to shift signed integers. To avoid the restriction, you need to manually define what is meant by "shift" signed things.All undefined behaviors and implementation-defined behaviors are handled this way: it's the user that must define them, otherwiser the compiler refuses to compile!-if it comes out garbage, it's not my fault- that's my approach

author: coppice
author_rank: Super Contributor
timestamp: December 08, 2024, 06:38:23 pm
content: Quote from: tggzzz on December 08, 2024, 04:16:40 pmHey, you are the one who started with the crappy analogy that fit like a meaningful response in 140 characters.

author: magic
author_rank: Super Contributor
timestamp: December 08, 2024, 06:52:56 pm
content: Bamboo is carbon negative and will remain available after the nuclear war. As will BASIC.Computers fast enough to compile R@#$ code within human lifetime, not certainlyThey know what they are doing.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: December 08, 2024, 06:57:40 pm
content: I am feeling less guilty about my ignorance of the complex data type in C. When googling C Data Types, the first five answers, starting with the new AI "summary", followed by Wikipedia and the next three returned responses don't mention a complex data type. Same with the 700 page C training book I got in 1997, even as a possibility for the future. So it didn't have complex data from its start at ATT, through its explosion in popularity, through ANSI C and the 1995 update. It seems that the vast majority of the users of the language didn't miss its absence much, and probably a significant proportion of that population is unaware of its availability to this day.

author: coppice
author_rank: Super Contributor
timestamp: December 08, 2024, 07:02:52 pm
content: Quote from: CatalinaWOW on December 08, 2024, 06:57:40 pmOh, we missed it. However, real world complex support entered the C world in such a late and piecemeal fashion, most of us who use a lot of complex data had already settled into our own way of doing things. Rather like the way that in a sane world we would have had things like int16_t from day one, but because we didn't there is still more code using other people's macro names than the standardised ones.

author: Marco
author_rank: Super Contributor
timestamp: December 08, 2024, 07:05:57 pm
content: Quote from: Doctorandus_P on December 04, 2024, 03:18:07 amBackwards compatibility is non negotiable. Swift will likely get a subset with all noncopyable types though, then there will be three somewhat mainstream borrow checked languages to choose from.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 09, 2024, 01:26:05 am
content: Quote from: DiTBho on December 08, 2024, 06:26:07 pmAnything implicit in a prog language is a gun pointed at your head. That's why Ada has a very strict typing behavior and pretty much no implicit anything.Implicit makes it look easy to use, until it backfires and you're then very sorry. So in a way, that's like languages for kids.As to bit shifting, there are various lines of thoughts.- The reasonable and rational: bit shifting on signed integers are "arithmetic shifts". Sign is preserved.- The bare one: bit shifting always done as pure bit shifting whatever the signedness (crazy, but simple).- Making bit shifting on signed integers UB. Even crazier.- And, as you proposed, making bit shifting on signed integers forbidden entirely. No question.Arithmetic shifting is like seeing the shifting as equivalent to a mulitply or divide by a power of 2. It's a higher-level operation.The general problem with UB is that any reasonable developer should consider "UB" as "forbidden" in general, but the standard says "do as you wish, I don't care". And so does the compiler. Sure it gives more flexibility for compilers.

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 10, 2024, 06:29:53 am
content: Arithmetic right-shiftoperation on negative numbers using two's complement format isn't exactly dividing by a power of two, because arithmetic right shift of \$v\$ by \$n\$ bits actually implements$$v^\prime = \begin{cases}\displaystyle \frac{v}{2^n}, & v \ge 0 \\\displaystyle \frac{v - 2^{n-1}}{2^n}, & v \le 0 \\\end{cases}$$That is, most current C compiler implementations yield(-63) >> 1 == -32but-63/2 == -31(-61) >> 2 == -16but-61/4 == -15(-57) >> 3 == -8but-57/8 == -7(-49) >> 4 == -4but-49/16 == -3because they use two's complement format for signed integers, and arithmetic right shift is the same as shifting the storage pattern right with new shifted-in bits getting the value of the original sign bit.In particular, forn> 0, we have(-1) >>n== -1.The mathematical properties and ease of integer negation and bit pattern inversion (they're supported by all instruction set architectures, and are extremely lightweight operations) is what makes this implementation superior, for both programmers and compiler writers.In particular, when you have an unsigned integer value with at least one most significant bit unused, negating the valuev, arithmetic right-shift bynbits, and negating the result again, implementsv' = (v>>n) + !!(v% (1 <<n))i.e., increments the result by one whenever any of the shifted bits out were nonzero. (!! is the not-not operator, which yields 0 if the operand is zero, and 1 if the operand is nonzero.) This is surprisingly commonly used during various padding calculations, and the most common way this is implemented isv' = 1 + ((v- 1) >>n)which yields the exact same results forv≥ 1, but has issues withv=0 (unless the arithmetic right shift is used for thev=0 case, such that (-1)>>n== -1).In both cases one or both of the negations, as well as the increment and/or decrement, can be merged with other operations in the same expression. The difference is only with howv=0 behaves. (Technically, the negation approach is also limited to half the range of the unsigned type, whereas the increment-shift-decrement supports the full range of the unsigned type except for zero.)This is also a perfect example of where practical exploration and competition can prove superior to carefully planned design.Any human language designer would be attracted to define negative right shift as the division by a power of two, because of the symmetries and apparent simplicity. However, only optimization work on actual real-life operations would tell such a designer that no, the desire for symmetry there is unwarranted, and because of practical code and machine implementations, being asymmetric this way following what the actual processors do, yields better performing code. Even the world of embedded computing is way too complex for any single human mind to comprehend, so at some point, the designer has to relinguish some control, and instead let the language evolve on its own, only holding the reins lightly –– like for a horse going home –– gently guiding the direction, instead of dictating directions and considerations.Quote from: tggzzz on December 08, 2024, 12:00:45 pmStrict focus: yes, definitely. You want to keep the overall shape and paradigm (approach to problem solving) clear, and avoid trying to cater to every single whim.Careful planning: In the latter stages,extensionsdo not need to be and should not be pre-planned; they can simply be experimented with as needed. Their inclusion into the standard proper, however, should be very carefully examined and investigated, to see if theyfit, do not break existing code, and do not pose other difficulties to existing implementations.In contrast, the core languagemustbe carefully planned beforehand. That part dictates what the approach to problem solving will be, and getting it even slightly wrong will require a new language; fixing such in backwards-compatible manner just does not work well enough (again, Python 2to3).I don't know if this is what you meant, though.In my opinion and experience, pre-planning possible extensions by language designers is a no-no for me, because they're limited to their own vision. Allowing nonstandard extensions to flourish, and thencarefullypick what will be included, in the "stable phase" of the language, is absolutely required for the language to staycurrentand as useful as possible in the long term. Heck, I even like having competing extensions, because that way a larger fraction of the possible extensions will be explored; and as long as the selection process is careful enough and fitting within the language, I claim will result in better development than any human pre-planners can achieve.(Of course, if you define that pre-planning that the extensions should be experimentally implemented first, before their inclusion in the language proper, then my needs are fulfilled. However, that also requires that language designers become compiler/interpreter implementers also, or at least work very closely with some. This is the crucial difference in my opinion: whether a language is fully defined as a theoretical construct first, or whether only its core, its idea, its paradigm is, with extensions and additions tested first and examined in practice, then modified, and finally selected for inclusion into the language.)

author: DiTBho
author_rank: Super Contributor
timestamp: December 10, 2024, 02:36:47 pm
content: Quote from: Nominal Animal on December 10, 2024, 06:29:53 amIn the early 90s, it was well described in computer science books written by people like Clements.I remember there were at least a couple of examples and exercises with solutions, very useful for practice.Nowadays almost nobody writes books that deal with these issues with assembly examples anymore.And there are even things that I don't find implemented in hardware.For example, without any software support, the MIPS5++ ISA does not offer any sign extensions for any shift operation.This is a bloody example of how you can do whatever you want as long as you know that you can't blame the compiler.If you get weird behavior, well that sort of thing is not supported by the hardware you are compiling for.

author: newbrain
author_rank: Super Contributor
timestamp: December 10, 2024, 02:49:10 pm
content: Quote from: SiliconWizard on December 09, 2024, 01:26:05 amThe way the C standard defines right shifts for negative integers is missing: implementation defined.QuoteThere's a very substantial difference between IDB and UB.OTOH, left shifts on signed integers that change the sign bitareUB.As discussed already (ISTR) that was a sane decision at the time the first standard came out.Probably much less now, and as C23 moved to forced 2's complement, they could have taken the step of defining the right shift as always being an arithmetic one. For the left shift I'm not taking position, but it's the same (undefined) behaviour as integer overflow - which is at least consistent.Quote from: Nominal Animal on December 10, 2024, 06:29:53 amThey should have gone the way of FORTH: integer division rounds towards minus infinity. Problem solved!

author: DiTBho
author_rank: Super Contributor
timestamp: December 10, 2024, 04:39:26 pm
content: Quote from: newbrain on December 10, 2024, 02:49:10 pmDo you like myC approach = compiler refuses to compile on { ID, UB } ?

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 11, 2024, 08:38:14 am
content: Quote from: newbrain on December 10, 2024, 02:49:10 pmYup!(I admit, I completely forgot that rounding towards negative infinity is also exactly equivalent here!)

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 11, 2024, 08:55:09 am
content: Quote from: Nominal Animal on December 11, 2024, 08:38:14 amYes, I was gonna reply to your post and this isn't needed now.Ultimately, the difference is indeed in the rounding. Either could be justified depending on the application. Of course, it's good to know that there can be a difference, although it's entirely implementation-defined when it comes to C and other languages. The underlying reason for this difference is of course the very low-level implementation (rtl/gate level), which is easier this way. The arithmetic shift right is just a matter of shifting everything right and copying the sign bit.The TLDR; would be never to use a right shift on signed integers in C if you want your code half-portable.If you don't care, while it's indeed implementation-defined, you'll find that on "most" modern targets and "most" compilers, the right shift on signed integers is just a classic arithmetic shift (due to it being available directly as an instruction on most targets), so if that's what you want and don't want to rely on inline assembly, then, you can always use that. After checking and at your own risk.

author: newbrain
author_rank: Super Contributor
timestamp: December 11, 2024, 09:49:00 am
content: Quote from: DiTBho on December 10, 2024, 04:39:26 pmA honest question:Does "refuses to compile IDB" mean it will not allow anything on Annex J.3 to pass compilation, or that a specific behaviour has been defined?In the latter case, that would no be any different from a C compiler.In the former, and the same holds for UB (J.2), how can you catch them all at compilation time?Many of both can possibly caught only at runtime (e.g. converting a double to float: it's IDB if the value fits, UB otherwise) unless the language is so far removed from C that the comparison is only syntactical (I think I remember heavy limitation on pointers?).While having a syntactically "comfort zone" language is not a bad idea, in this case I'd personally go for something less niche - most likely, Rust (yes, Rust has its problems too) - also to help me compartmentalize my habits and idioms.EtA: UB annex chapter, and an extra question: What about J.1, Unspecified behaviour?

author: Nominal Animal
author_rank: Super Contributor
timestamp: December 11, 2024, 11:21:48 am
content: Quote from: SiliconWizard on December 11, 2024, 08:55:09 amI disagree, literally because I haven't encountered a C compiler that did not implement right shift on signed integers as an arithmetic right shift. To me, this ispracticallyportable across all architectures I've been interested in thus far, and that's quite a few.I do insist that it and other expectations on such implementation-defined behaviour should be well documented in the project, though; preferably including build tests/checks that lets builders/integrators check and verify.This is what I aim to do, and I do claim it makes such projects –– even when those projects go beyond the text of ISO Standard C and occasionally even beyond POSIX C or GNU C domains –– more portable than only using allegedly strictly standards-compliant code. It isn't "clean" so to speak, but it is very practical.That said, I do usually check the alternate forms of the same expressions avoiding implementation-defined behaviour, to see if the compilers I use generate acceptable code. (No need to be optimal, though; I only want to avoid the pathologically bad cases.) If they do, then I use the standards-compliant expressions. Godbolt.org is an excellent resource for this.Quote from: SiliconWizard on December 11, 2024, 08:55:09 amThere is always a certain amount of risk when using C, because there is disagreement on the exact interpretation of the details of the C standard. As someone who writes C code, I firmly believe the developer shouldalwaysacknowledge that risk, and bear the consequences.You see, in my opinion, developers should always be responsible for the real-world end product they publish. This means that if compilers used have a bug, the developer should feel responsible for working around that bug until the compilers fix it on their end, instead of throwing ones hands up that "it's not in my code, I'm not responsible!". (I don't mean any bug in any version; only in most commonly used current versions. Responding that "I would do the workaround if it impacted more users, but I just cannot allocate the time needed for this right now" is perfectly okay.)The point I'm trying to make here is that even if you follow the standards to the letter, a developer should not feel like it takes away their risk or responsibility of the end product. Thus, using and documenting extensions and expected implementation details is acceptable –– it is, after all, how thePOSIX Cstandard ensures portability with respect to deviations from ISO C.

author: DiTBho
author_rank: Super Contributor
timestamp: December 11, 2024, 04:15:38 pm
content: Quote from: newbrain on December 11, 2024, 09:49:00 ammyC is strongly typed and beats its user hard.Each type carries with it properties and operators that "may" or "may not" be defined.If they are not, the compiler refuses to compile.Above, we were talking about operations defined on a data type, the "signed type"on uint(x)_t, with x equal to the bits of the CPU registers {8, 16, 32, 64, ...}, all the logical and arithmetic operations supported by the CPU are defined by default, and should be careful that if something is not defined in the machine layer because it is not supported by the hw, then the compiler refuses to compile explicitly reporting the problem.on sint(x)t instead, no operation involving shifts, or bitset/tst/get, etc. is defined, and therefore the compiler simply refuses to compile if you try to use them.If you insist on using them, you need to define all operations in a machine-level extension.For all types (including boolean_t), the range is always checked at runtime. If something goes out of range, an exception is immediately raised.You can also define "subrange", e.g. uint8_t i0'subrange={0...10}; and be careful that this also includes the range of validity of the iterators, which must be written in a particular way, otherwise when it exits the loop the value of the iterator could be "10+1" and an exception is raised!uint8_t i0'subrange={0...10};for (i0=0; i0=<10; i0++) { } <------- won't work!uint8_t i0'subrange={0...11};for (i0=0; i0=<10; i0++) { } <------- will work!uint8_t i0;for (i0=0; i0=<10; i0++) { } <------- will work!There is no overflow, there is no underflow, and there is absolutely no "casting" as is done in CTo go from one type to another, you need to define "bridge function", which expressly express how to go from one type to another, and the valid criteria for validity, so, once again, the range!

author: newbrain
author_rank: Super Contributor
timestamp: December 11, 2024, 05:39:47 pm
content: Thanks!So you 'undefined' all behaviour unless explicitly described.I think the first two example should have a "<=" rather than a "<" ?I gather that by "no casting" you also include "no automatic promotion/demotion", summing a uint8_t{0...10} to a int16_t{-1000...1000} and assigning the result to an int32_t or, worse, to a uint32_t will then need a number of explicit conversions?The type system is similar (in representation, names, syntax...) to C, but totally different in semantics, I see (pun half-intended).Checking overflow and throwing an exception (IIUC the mechanism) on all operation (and libraries!) is going to incur in a heavy runtime cost, apart from the cases when it can be proved not to occur at compilation time, but I understand the intent and it can be warranted in your context.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 11, 2024, 06:04:37 pm
content: Quote from: DiTBho on December 10, 2024, 04:39:26 pmI think that is a convoluted way of saying "my language does not have implementation defined or undefined behavior".Which is very sensible design.

author: DiTBho
author_rank: Super Contributor
timestamp: December 15, 2024, 10:11:07 am
content: Quote from: newbrain on December 11, 2024, 05:39:47 pmPreciselyQuoteYes, talking about the implementation of myC, this is a serious problem because that "language feature" increases the code size and reduces the speed.If you compare the binary code produces (same C source) by gcc-mips32 with the code produces by myC-mips32 (in c/89 compatibility mode), it's significantly slower and takes up many more Kb.The above example is not even optimal for an ICE connected to a myC-dbgTAP.Instead of sub-ranging a "variable" it is better to define a "new type", derived from a primary type (e.g. uint32_t) with a limited range, and then use the new type for a variable.It makes debugging much easier, and faster.myC has a local (per function) "variable space" which has to be loaded at every "function call", and a global "type space", a table that is loaded into memory in session crt0.Both describe objects in terms of properties, the "variable space" is on demand.The subrange property is there, in the table. By addressing the table by "type-id" or by "var-id" at runtime, the range-check has to- load the range from the table- check if the register content is within the range- trap if it's notAlways many loads and comparisons

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 15, 2024, 11:45:56 pm
content: Not leaving anything ID or UB is good, but one has to realize it's much harder than it looks.Yes, sometimes this is intentional (like, some parts of the C standard that leave some things ID or UB to *potentially* allow compilers to be simpler or yield more efficient code), and that part can be deemed questionable.But the reality is that many of the ID or UB parts of C initially come from missing specs (things that were overlooked), then developers start to count on specific behaviors of the available compilers, then years later, standard comittees decide that these missing specs must be mentioned, but they can't make them anything other than ID or UB, which could potentially break existing code all over the place. That's the (sometimes sad) reality.When designing a new language, it's a good idea to try and identify as many of these cases and not make them open questions (so no ID or UB). It's also easier to do now that there is literally decades of experience in programming. But being exhaustive is kind of an elusive goal, and so there will probably always be some edge case that we have forgotten to specify, and existing code bases will hinder change.The lack of a formal specification makes it all even harder. If all you have is a compiler (so, software itself) to define a programming language, then you are at the complete mercy of its implementation and you may rely on compiler behaviors that you don't even completely grasp, you just observe that "it appears to work". Yes Rust, I'm looking at you.

author: DiTBho
author_rank: Super Contributor
timestamp: December 16, 2024, 07:27:09 am
content: Quote from: SiliconWizard on December 15, 2024, 11:45:56 pmeh, I don't know how many languages ​​- excecpt Ada - have a formal spec.Maybe only academic things, and not even well done.As far as I know, in the various advanced academic courses you never touch anything really useful.Not even years later when you grew up with the industry.That's life in Computer Science

author: Siwastaja
author_rank: Super Contributor
timestamp: December 16, 2024, 08:11:00 am
content: Quote from: SiliconWizard on December 15, 2024, 11:45:56 pmThis is why it would be interesting to see a "new C" which is allowed to break compatibilityfor good reasons- for example removal of IDB/UB -, but doesn't try to turn everything upside down and invent a completely new language either. Because when you do that, you lose the wisdom collected over the years, and will repeat many of the same mistakes again.I mean, I'm not a big fan of the Python 2->3 transition but that demonstrates such a thing can be done.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 16, 2024, 08:23:16 am
content: While I'm not a fan of the name, Zig kind of does that.

author: cfbsoftware
author_rank: Regular Contributor
timestamp: December 16, 2024, 09:45:43 pm
content: Quote from: DiTBho on December 16, 2024, 07:27:09 amModula-2 underwent a rigorous, but excruciating formalisation process. See "ISO/IEC 10514-1, the standard for Modula-2: Process Aspects" for some of the issues involved:https://dl.acm.org/doi/pdf/10.1145/242903.242950The guys working on the Rust specification would do well to study that process before going too far.https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 16, 2024, 09:59:25 pm
content: Quote from: cfbsoftware on December 16, 2024, 09:45:43 pmYep. Thanks for the paper - should be a good read.And while one may argue to no end that standards are not "formal specs" (however we want to define this), any standardized language can be considered having one. Unless you like nitpicking.Point is - whether it's a standard or not, you need a spec good enough to allow developing compilers that will compile the same code yielding the same observable result, and likewise allow developers to write code that will work with any compliant compiler.That is undoubtedly the case with C and Ada (if one excludes bugs rather than lack of specs). Probably also C++, although it's so complex that it's hard to validate.Since a new language can't get a standard before years (or sometimes decades), a spec is all you can have early on.The absence of a spec (formal enough that it is reasonably unambiguous and authoritative) prevents any third-party from writing compilers and any developer from writing code they'll be sure will be correct ten or twenty years from now, which is game over in my book.

author: westfw
author_rank: Super Contributor
timestamp: December 23, 2024, 06:52:34 am
content: Rude question:Is BASIC a memory-safe language? Could it be?

author: magic
author_rank: Super Contributor
timestamp: December 23, 2024, 06:57:04 am
content: IIRC, Microsoft Visual Basic and Quick Basic were memory safe(With exception of the latter offering peek/poke instructions.)There was indeed a plan to rewrite Linux as a microkernel in a message-passing dialect of Visual Basic.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 23, 2024, 07:51:16 am
content: Quote from: magic on December 23, 2024, 06:57:04 am

author: magic
author_rank: Super Contributor
timestamp: December 23, 2024, 08:29:54 am
content: It was supposed to be the 3.0 release, but it didn't happenhttps://lkml.org/lkml/2005/3/2/247

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 23, 2024, 08:54:13 am
content: I didn't know he wrote that, but it was quite a funny one.Quote

author: magic
author_rank: Super Contributor
timestamp: December 23, 2024, 09:19:50 am
content: Speaking of microkernels written in a memory safe version of Visual Basic, I have heard that Redox is nearly 10 years old and still doesn't even have working USB support.Linux did have USB in 2001, so I guess that's a win for languages which make it possible to write, compile and run sloppy code. People will use such software if its price is right, but they won't use something that doesn't run merely because it isn't correct, or written yet because of pedantry and analysis paralysis.This will trigger both Linux and R&$# fanboys, but I think that Linux (and certainly its HW drivers) owes its existence to C, and for the same reasons Redox will owe its non-existence to R&$#

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 23, 2024, 09:52:49 pm
content: Agreed.The language may not be the only issue though - I think the overall attitude plays a big role too. But it's tightly linked to Rust, so it's hard to tell which came first.

author: DiTBho
author_rank: Super Contributor
timestamp: December 24, 2024, 04:37:16 pm
content: rewriting the Linux kernel in a different language is... just impossible.It's already a problem toto support different kernel families, for example you can't compile kernel 6.12 with gcc v<10, and it's compiled with many scripts, some in perl, some in bash... some depend on "Makefile", early 2000s is not compatible with 2010s, which is not compatible with 2020s, ...to separate the sources from the objects, let's say you want to share the sources with different platforms, you have to clone the folder over and overForget it.

author: DiTBho
author_rank: Super Contributor
timestamp: December 24, 2024, 04:49:03 pm
content: I tried to write a simple kernel module for Linux.myC does not produce assemblies compatible with GNU binutils, so I had to put it against a translatormyC -> myAS -> myAS to GAS/mips32 -> object fileAlthough it apparently compiles successfully, all the monad support is missing, because standard C doesn't need it.So kernel panics as soon as you load the module.There's more work to do and I don't know if it makes sense to do it...

author: westfw
author_rank: Super Contributor
timestamp: December 25, 2024, 02:58:37 am
content: It seems to me that the problem with "memory safe" languages, is that all the libraries and run-time support has to be memory-safe as well. That tends to make such languages either very large and difficult to implement (like Ada or Java), or (and/or?) ... unable to do the things that need to be done (USB support being a fine example, I guess.)C has the advantage that it CAN do anything; just set a pointer to your hardware registers and off you go! And it doesn't HAVE to do anything in the language; write a few basic math functions and a bit of startup code, and you can say you have a C compiler (POSIX and LIBC be damned!)

author: tggzzz
author_rank: Super Contributor
timestamp: December 25, 2024, 08:01:14 am
content: Quote from: westfw on December 25, 2024, 02:58:37 amJava:C languages is like digital:analogue circuits.Typical applications are large programs, and the the interaction between all parts is too complex to understand. The runtime support is much smaller and more constrained, and should therefore have interactions and be easier to understand.That basic principle occurs in many places, e.g. the difference between analogue and digital circuits. Analogue circuits can do every thing digital circuits can and more, but guess which allows more complex systems. In addition, many people forget that digital circuits are analogue circuits operating in a constrained mode - usually, until so something subtle bites them. Simple example: DRAM - analogue or digital? Which is more usable?If you think C (worse C++) is a simple language, then you really don't understand the subtleties. In the 90s compiler writers frequently had to ask what the standard meant - and conflicting answers from different committee members. Disgraceful.Java is a much simpler language.