You've got an off-by-one bug there. Should be:

int sod(int n)
{
   int m;
   return ((m=(n)?n%10+sod(n/10):0)>=10)?sod(m):m;
}

Oh hey, I just ran my program on the number 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621162216231624162516261627162816291630163116321633163416351636163716381639164016411642164316441645164616471648164916501651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684168516861687168816891690169116921693169416951696169716981699170017011702170317041705170617071708170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768176917701771177217731774177517761777177817791780178117821783178417851786178717881789179017911792179317941795179617971798179918001801180218031804180518061807180818091810181118121813181418151816181718181819182018211822182318241825182618271828182918301831183218331834183518361837183818391840184118421843184418451846184718481849185018511852185318541855185618571858185918601861186218631864186518661867186818691870187118721873187418751876187718781879188018811882188318841885188618871888188918901891189218931894189518961897189818991900190119021903190419051906190719081909191019111912191319141915191619171918191919201921192219231924192519261927192819291930193119321933193419351936193719381939194019411942194319441945194619471948194919501951195219531954195519561957195819591960196119621963196419651966196719681969197019711972197319741975197619771978197919801981198219831984198519861987198819891990199119921993199419951996199719981999200020012002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026202720282029203020312032203320342035203620372038203920402041204220432044204520462047204820492050205120522053205420552056205720582059206020612062206320642065206620672068206920702071207220732074207520762077207820792080208120822083208420852086208720882089209020912092209320942095209620972098209921002101210221032104210521062107210821092110211121122113211421152116211721182119212021212122212321242125212621272128212921302131213221332134213521362137213821392140214121422143214421452146214721482149215021512152215321542155215621572158215921602161216221632164216521662167216821692170217121722173217421752176217721782179218021812182218321842185218621872188218921902191219221932194219521962197219821992200220122022203220422052206220722082209221022112212221322142215221622172218221922202221222222232224222522262227222822292230223122322233223422352236223722382239224022412242224322442245224622472248224922502251225222532254225522562257225822592260226122622263226422652266226722682269227022712272227322742275227622772278227922802281228222832284228522862287228822892290229122922293229422952296229722982299230023012302230323042305230623072308230923102311231223132314231523162317231823192320232123222323232423252326232723282329233023312332233323342335233623372338233923402341234223432344234523462347234823492350235123522353235423552356235723582359236023612362236323642365236623672368236923702371237223732374237523762377237823792380238123822383238423852386238723882389239023912392239323942395239623972398239924002401240224032404240524062407240824092410241124122413241424152416241724182419242024212422242324242425242624272428242924302431243224332434243524362437243824392440244124422443244424452446244524442443244224412440243924382437243624352434243324322431243024292428242724262425242424232422242124202419241824172416241524142413241224112410240924082407240624052404240324022401240023992398239723962395239423932392239123902389238823872386238523842383238223812380237923782377237623752374237323722371237023692368236723662365236423632362236123602359235823572356235523542353235223512350234923482347234623452344234323422341234023392338233723362335233423332332233123302329232823272326232523242323232223212320231923182317231623152314231323122311231023092308230723062305230423032302230123002299229822972296229522942293229222912290228922882287228622852284228322822281228022792278227722762275227422732272227122702269226822672266226522642263226222612260225922582257225622552254225322522251225022492248224722462245224422432242224122402239223822372236223522342233223222312230222922282227222622252224222322222221222022192218221722162215221422132212221122102209220822072206220522042203220222012200219921982197219621952194219321922191219021892188218721862185218421832182218121802179217821772176217521742173217221712170216921682167216621652164216321622161216021592158215721562155215421532152215121502149214821472146214521442143214221412140213921382137213621352134213321322131213021292128212721262125212421232122212121202119211821172116211521142113211221112110210921082107210621052104210321022101210020992098209720962095209420932092209120902089208820872086208520842083208220812080207920782077207620752074207320722071207020692068206720662065206420632062206120602059205820572056205520542053205220512050204920482047204620452044204320422041204020392038203720362035203420332032203120302029202820272026202520242023202220212020201920182017201620152014201320122011201020092008200720062005200420032002200120001999199819971996199519941993199219911990198919881987198619851984198319821981198019791978197719761975197419731972197119701969196819671966196519641963196219611960195919581957195619551954195319521951195019491948194719461945194419431942194119401939193819371936193519341933193219311930192919281927192619251924192319221921192019191918191719161915191419131912191119101909190819071906190519041903190219011900189918981897189618951894189318921891189018891888188718861885188418831882188118801879187818771876187518741873187218711870186918681867186618651864186318621861186018591858185718561855185418531852185118501849184818471846184518441843184218411840183918381837183618351834183318321831183018291828182718261825182418231822182118201819181818171816181518141813181218111810180918081807180618051804180318021801180017991798179717961795179417931792179117901789178817871786178517841783178217811780177917781777177617751774177317721771177017691768176717661765176417631762176117601759175817571756175517541753175217511750174917481747174617451744174317421741174017391738173717361735173417331732173117301729172817271726172517241723172217211720171917181717171617151714171317121711171017091708170717061705170417031702170117001699169816971696169516941693169216911690168916881687168616851684168316821681168016791678167716761675167416731672167116701669166816671666166516641663166216611660165916581657165616551654165316521651165016491648164716461645164416431642164116401639163816371636163516341633163216311630162916281627162616251624162316221621162016191618161716161615161416131612161116101609160816071606160516041603160216011600159915981597159615951594159315921591159015891588158715861585158415831582158115801579157815771576157515741573157215711570156915681567156615651564156315621561156015591558155715561555155415531552155115501549154815471546154515441543154215411540153915381537153615351534153315321531153015291528152715261525152415231522152115201519151815171516151515141513151215111510150915081507150615051504150315021501150014991498149714961495149414931492149114901489148814871486148514841483148214811480147914781477147614751474147314721471147014691468146714661465146414631462146114601459145814571456145514541453145214511450144914481447144614451444144314421441144014391438143714361435143414331432143114301429142814271426142514241423142214211420141914181417141614151414141314121411141014091408140714061405140414031402140114001399139813971396139513941393139213911390138913881387138613851384138313821381138013791378137713761375137413731372137113701369136813671366136513641363136213611360135913581357135613551354135313521351135013491348134713461345134413431342134113401339133813371336133513341333133213311330132913281327132613251324132313221321132013191318131713161315131413131312131113101309130813071306130513041303130213011300129912981297129612951294129312921291129012891288128712861285128412831282128112801279127812771276127512741273127212711270126912681267126612651264126312621261126012591258125712561255125412531252125112501249124812471246124512441243124212411240123912381237123612351234123312321231123012291228122712261225122412231222122112201219121812171216121512141213121212111210120912081207120612051204120312021201120011991198119711961195119411931192119111901189118811871186118511841183118211811180117911781177117611751174117311721171117011691168116711661165116411631162116111601159115811571156115511541153115211511150114911481147114611451144114311421141114011391138113711361135113411331132113111301129112811271126112511241123112211211120111911181117111611151114111311121111111011091108110711061105110411031102110111001099109810971096109510941093109210911090108910881087108610851084108310821081108010791078107710761075107410731072107110701069106810671066106510641063106210611060105910581057105610551054105310521051105010491048104710461045104410431042104110401039103810371036103510341033103210311030102910281027102610251024102310221021102010191018101710161015101410131012101110101009100810071006100510041003100210011000999998997996995994993992991990989988987986985984983982981980979978977976975974973972971970969968967966965964963962961960959958957956955954953952951950949948947946945944943942941940939938937936935934933932931930929928927926925924923922921920919918917916915914913912911910909908907906905904903902901900899898897896895894893892891890889888887886885884883882881880879878877876875874873872871870869868867866865864863862861860859858857856855854853852851850849848847846845844843842841840839838837836835834833832831830829828827826825824823822821820819818817816815814813812811810809808807806805804803802801800799798797796795794793792791790789788787786785784783782781780779778777776775774773772771770769768767766765764763762761760759758757756755754753752751750749748747746745744743742741740739738737736735734733732731730729728727726725724723722721720719718717716715714713712711710709708707706705704703702701700699698697696695694693692691690689688687686685684683682681680679678677676675674673672671670669668667666665664663662661660659658657656655654653652651650649648647646645644643642641640639638637636635634633632631630629628627626625624623622621620619618617616615614613612611610609608607606605604603602601600599598597596595594593592591590589588587586585584583582581580579578577576575574573572571570569568567566565564563562561560559558557556555554553552551550549548547546545544543542541540539538537536535534533532531530529528527526525524523522521520519518517516515514513512511510509508507506505504503502501500499498497496495494493492491490489488487486485484483482481480479478477476475474473472471470469468467466465464463462461460459458457456455454453452451450449448447446445444443442441440439438437436435434433432431430429428427426425424423422421420419418417416415414413412411410409408407406405404403402401400399398397396395394393392391390389388387386385384383382381380379378377376375374373372371370369368367366365364363362361360359358357356355354353352351350349348347346345344343342341340339338337336335334333332331330329328327326325324323322321320319318317316315314313312311310309308307306305304303302301300299298297296295294293292291290289288287286285284283282281280279278277276275274273272271270269268267266265264263262261260259258257256255254253252251250249248247246245244243242241240239238237236235234233232231230229228227226225224223222221220219218217216215214213212211210209208207206205204203202201200199198197196195194193192191190189188187186185184183182181180179178177176175174173172171170169168167166165164163162161160159158157156155154153152151150149148147146145144143142141140139138137136135134133132131130129128127126125124123122121120119118117116115114113112111110109108107106105104103102101100999897969594939291908988878685848382818079787776757473727170696867666564636261605958575655545352515049484746454443424140393837363534333231302928272625242322212019181716151413121110987654321

Looks like the sum is 4!

Very good test and yes it is 4, I think this is also called the "digital root", that's an interesting implementation.

 

This is off-topic, so I will keep it very brief. @ApacheKid, do you know about PWAs? I know that you are using .NET and so Blazor is particularly useful, but PWAs are “free” and not-quite-but-soon-to-be universal when Apple gets its act together. (Apple effectively invented PWAs as the original idea for apps on the iPhone, but the idea didn’t catch on and they just dropped it on the floor).

I've read only a smattering about progressive web apps, I do find MAUI quite interesting, as a former WPF developer I miss the elegance of XAML and the hybrid MAUI-Blazor ideas are very interesting.

The main attraction of Blazor (to me) is the option to more or less abandon Javascript and build a web app in a single language, the hassle caused by supporting two languages is huge sometimes, the amount of wasted time can be incredible, in addition to which we have Javascript itself with its loose typing and other "features".

 

Actually we don't need recursion, I was wrong, we can that's fine, but it's not essential, here is an iterative implementation:

int map[10][10] =
{
    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, // 0
    {1, 2, 3, 4, 5, 6, 7, 8, 9, 1}, // 1
    {2, 3, 4, 5, 6, 7, 8, 9, 1, 2}, // 2
    {3, 4, 5, 6, 7, 8, 9, 1, 2, 3}, // 3
    {4, 5, 6, 7, 8, 9, 1, 2, 3, 4}, // 4
    {5, 6, 7, 8, 9, 1, 2, 3, 4, 5}, // 5
    {6, 7, 8, 9, 1, 2, 3, 4, 5, 6}, // 6
    {7, 8, 9, 1, 2, 3, 4, 5, 6, 7}, // 7
    {8, 9, 1, 2, 3, 4, 5, 6, 7, 8}, // 8
    {9, 1, 2, 3, 4, 5, 6, 7, 8, 9}, // 9
};

int sumofdigits(int * digits_ptr)
{
    int sum = 0;

    while (*digits_ptr != -1)
    {
        sum = map[sum][*(digits_ptr++)];
    }

    return sum;
}

The 2D map can be made a lot smaller with a little effort, but that would mask what's happening, the 2D makes it clear, clear that arithmetic is just symbol manipulation which any "hardware guy" should already know if they've studied 2 bit adders, a familiar hardware abstraction if I'm not mistaken, but if you think in C you'll miss all that as some people here did.

    int digits[] = { 1, 4, 7, 3, 8, 1, 0, 3, 7, 2,-1 };

    int x = sumofdigits(digits);

    // x = 9

The algorithm can support any length of input too, a hundred billion digits, no problem, so long as machine resources are sufficient. This is also very well behaved in the time domain, the time to compute the result is a simple function of the number of digits to be processed, sometimes a very desirable feature in real time MCU based systems...

For anyone interested, here's a solution in F#, a functional language:

let condense digits =
    digits |> Seq.reduce (fun x y -> [|0;1;2;3;4;5;6;7;8;9;1;2;3;4;5;6;7;8;9|].[x + y])

This is uses a 1D array and adds two of the input digits to compute the subscript.

 

It is an interesting problem domain, I am too far removed from it to really appreciate the kinds of things involved though, but as soon as I started to play with Verilog I said "Ahh, no surprises here, designed to 'look like' C".

I'm not sure that was intentional, but it might have been (it certainly came after 'C'); VHDL on the other hand, comes from Ada, partly because it was funded by the DoD (as was Ada) so they intentionally wanted a convergence of software and HDL languages, and that makes it a bit more object oriented (and verbose!) than Verilog. It also has most of the "features" of SystemVerilog already built in (thanks to the Ada roots again).

As for your other hypothesis: all these languages are Turing-complete so one isn't really more powerful than another, it's just a matter of expressivity (how easy it is to express a, possibly complex, concept in code). You might be making something of a Sapir-Whorf claim that language influences thought, but recent research hasn't shown an actual correlation (if anything, it's the reverse), but I guess in some way I agree with you, at least professionally I used 'C' after assembly and before 'Lisp', and my 'C' code looks much like my assembler code did (well, more succinct perhaps), while once I began using Lisp regularly I started coding very differently. And then there was PROLOG...

 

I'm not sure that was intentional, but it might have been (it certainly came after 'C'); VHDL on the other hand, comes from Ada, partly because it was funded by the DoD (as was Ada) so they intentionally wanted a convergence of software and HDL languages, and that makes it a bit more object oriented (and verbose!) than Verilog. It also has most of the "features" of SystemVerilog already built in (thanks to the Ada roots again).

As for your other hypothesis: all these languages are Turing-complete so one isn't really more powerful than another, it's just a matter of expressivity (how easy it is to express a, possibly complex, concept in code). You might be making something of a Sapir-Whorf claim that language influences thought, but recent research hasn't shown an actual correlation (if anything, it's the reverse), but I guess in some way I agree with you, at least professionally I used 'C' after assembly and before 'Lisp', and my 'C' code looks much like my assembler code did (well, more succinct perhaps), while once I began using Lisp regularly I started coding very differently. And then there was PROLOG...

The root of my dissatisfaction with C and the many derivates, is the grammar. It is a poor grammar in several respects and as soon as a decision is made to "make it look like C" the damage is done, here's a summary:

• Putting type before name in declarations.
• Reliance on reserved words rather than keywords.
• The useless "void" keyword.
• Permitting a function to be called (disregarding its return value).
• Absence of nested functions.
• Need for forward declarations.
• Absence of a "bit" data type.
• Absence of string data types.

and various others (granted, not all of these are grammar issues).

A major consequence of this is that the language cannot be extended easily if at all, adding new keywords will likely break some existing code out there, adding new keywords breaks backward compatibility.

The motivation for C was fine in its day, at the time, it was devised to be easy to parse and create working compilers pretty quickly, but that carries a cost to this day, even C++, C#, Java and many others suffers - IMHO - from this fallout.

I am genuinely curious about what kind of language could emerge from real world MCU requirements along with an abandonment of this cumbersome C grammatical baggage.

I wasn't aware of the Ada connection to VHDL, Ada is a huge leap forwards, I was reading recently about how Nvidia are adopting Ada (in some way) for all future embedded development.

I strongly suspect that "void" exists to represent "nothing" because the grammar is otherwise impossible to parse. leaving "void" off some void function definition, makes the parsing impossible I suspect. So "void" was bolted on to eliminate that grammar problem, these kinds of decisions really are not good language design.

 

• Reliance on reserved words.
• Permitting a function to be called (disregarding its return value).

Well I'll agree with most of the things you dislike about 'C' I also dislike. But are there any computer languages without "reserve words"? Even if terms can be overloaded, there's usually some terms (symbols, etc.) that are part of the metalanguage so can't be redefined (without disaster anyway). Sure you CAN redefine, e.g., CAR in Lisp, but if you do, everything breaks (well at least in interpreted Lisp).

Your second point has more to do with side-effects and I'm not sure there are any truly successful side-effect free languages. Particularly if we consider typically unmodeled side effect a hardware engineer would care about like power consumption, time, memory, etc. then even "functional" languages are not really side-effect free unless we are in a "philosophy space" where everything that is true is true ab initio.

 

There are a few languages without reserved words, the grammar is defined so that a keyword could be used for an identifier, nobody would do that intentionally, but its there to allow new keywords without breaking existing code. PL/I is the best example but there are others too, I believe FORTRAN also has no reserved words.

A grammar in which there are two broad kinds of statements, keyword statements and assignments, lends itself to having no reserved words.

Any statement that is not an assignment is treated as beginning with a keyword. So this is legal:

if else then
   if = then;
else
   then = else;

If we wrote code like this

do while (yield)
{
   a = a + 1;
}

Where "yield" is a bool say. Well that code would not break if we now added a "yield" keyword to the language:

do while (yield)
{
   a = a + 1;
}

if (a > 100)
   yield a;

The vast majority of programming languages cannot support new keywords this flexibly, even C# has problems despite various heuristics.

I've developed compilers so I regard myself as having good insights into these issues, I even developed a PL/I compiler for windows some time back and so managed to implement the "no reserved words" feature. It wasn't hard at all actually, easier that it might at first sight seem.

This parses fine, absolutely no problems:

 

Really isn't true, only one person considered a recursive solution for example.

What makes you think that someone that showed an iterative solution didn't consider a recursive one? My first thought was a recursive approach, but why use that when a simple iterative loop with a single statement will suffice without the potential burden of the function-calling overhead. Furthermore, it's impossible to write a recursive solution that meets your specifications, one of which was that the input could be arbitrarily long. Even if the function is written so that it is tail-recursive, the compiler is under no requirement to convert that to an iterative implementation and thus there can be a finite length for which the input string blows the stack.

All the solutions too emphasize arithmetic addition as part of the processing, these are the kinds of things that subliminally influence the solution, the fact that many can only "see" the problem through the lens of C, if you use a single programming language routinely in professional work for long enough, it starts to act a "blinkers" and one can't see the wood for the trees.

Quite the contrary, for most people the approach is driven by how they would do it manually on paper. Ask someone that has never programmed anything in their life to come up with an algorithm to solve that problem, and they will almost certainly come up with an iterative approach that walks across the sequence of digits one digit at a time and, for each digit, adds that digit to a running total. At that point, some of them will implicitly apply the same algorithm recursively to the result until is reduced to a single digit, while others will reduce the running total to a single digit at each step.

It can even reach the point where the language itself becomes the be all and end all of problem solving, any suggestion that there might be other, better ways becomes anathema.

Define "better". You placed no restrictions on the solution other than correctness of the result and the ability to work with arbitrarily long sequences; thus, there is no metric by which to decide if one solution is better than another. Present nearly any two reasonable solutions (with 'reasonable' basically meaning that the solution isn't arbitrarily contrived to be 'poor') and I can probably come up with two sets of reasonable metrics one of which favors the first and the other favors the second.

The problem can in fact be reduced to a recursive state machine, no arithmetic addition required, no addition of digits, no arithmetic at all, almost childishly simple. But it is unlikely that most C programmers will find that kind of solution because C does indeed direct how they think about data processing problems.

You want a solution that uses a state machine. Fine. C is a perfectly suitable language for that and there are several ways to do it. Using a switch() statement is the obvious one, but leveraging the language requirement that the codes used for the digits '0' through '9' be sequential and in that order allows for a simple shortcut.

int sod_fsm(char *s)
{
    // This code creates the FSM transition table, but only once
    // This could be hard-coded as the map initializer
    static char map['9'+1][10] = {0};
    if (!(*(char *)map)++)
        for (int d = 0; d < 10; d++)
            for (int a = '0'; a <= '9'; a++)
                map[a][d] = (a - '0') + d - 9*((a - '0') + d > 9);
       
    // This is the code that runs the FSM on the input string    
    int total;
    for (total = 0; *s; s++)
        total  = map[*s][total];
   
    return total;
}

The examples supplied above use addition, subtraction, division, modulo division...

So? Again, your problem specification included nothing that would or should bias the solution against using them, though it could be argued that the 'arbitrary length' specification implies that speed of execution is a factor that could be considered (which would also bias against a recursive approach).

You are really making a straw man argument. You pose a problem in which YOU have a particular solution in mind, but set up the problem statement such that there is no reason to choose your solution over any other solution, then when people don't read your mind and choose your solution, you claim that it is somehow proof, or at least evidence, of whatever point you want to make, whether there is actually any linkage at all.

 

What makes you think that someone that showed an iterative solution didn't consider a recursive one? My first thought was a recursive approach, but why use that when a simple iterative loop with a single statement will suffice without the potential burden of the function-calling overhead. Furthermore, it's impossible to write a recursive solution that meets your specifications, one of which was that the input could be arbitrarily long. Even if the function is written so that it is tail-recursive, the compiler is under no requirement to convert that to an iterative implementation and thus there can be a finite length for which the input string blows the stack.



Quite the contrary, for most people the approach is driven by how they would do it manually on paper. Ask someone that has never programmed anything in their life to come up with an algorithm to solve that problem, and they will almost certainly come up with an iterative approach that walks across the sequence of digits one digit at a time and, for each digit, adds that digit to a running total. At that point, some of them will implicitly apply the same algorithm recursively to the result until is reduced to a single digit, while others will reduce the running total to a single digit at each step.



Define "better". You placed no restrictions on the solution other than correctness of the result and the ability to work with arbitrarily long sequences; thus, there is no metric by which to decide if one solution is better than another. Present nearly any two reasonable solutions (with 'reasonable' basically meaning that the solution isn't arbitrarily contrived to be 'poor') and I can probably come up with two sets of reasonable metrics one of which favors the first and the other favors the second.



You want a solution that uses a state machine. Fine. C is a perfectly suitable language for that and there are several ways to do it. Using a switch() statement is the obvious one, but leveraging the language requirement that the codes used for the digits '0' through '9' be sequential and in that order allows for a simple shortcut.

int sod_fsm(char *s)
{
    // This code creates the FSM transition table, but only once
    // This could be hard-coded as the map initializer
    static char map['9'+1][10] = {0};
    if (!(*(char *)map)++)
        for (int d = 0; d < 10; d++)
            for (int a = '0'; a <= '9'; a++)
                map[a][d] = (a - '0') + d - 9*((a - '0') + d > 9);

    // This is the code that runs the FSM on the input string
    int total;
    for (total = 0; *s; s++)
        total  = map[*s][total];

    return total;
}

So? Again, your problem specification included nothing that would or should bias the solution against using them, though it could be argued that the 'arbitrary length' specification implies that speed of execution is a factor that could be considered (which would also bias against a recursive approach).

You are really making a straw man argument. You pose a problem in which YOU have a particular solution in mind, but set up the problem statement such that there is no reason to choose your solution over any other solution, then when people don't read your mind and choose your solution, you claim that it is somehow proof, or at least evidence, of whatever point you want to make, whether there is actually any linkage at all.

I don't disagree with much of what you say here. The impetus for the exercise was this comment from nsaspook:

That influence maybe stifles you but to most of us, it's not a show-stopper because we don't think in C or any programming language, we think about physical machines physics and mechanical properties that are much more complex, complicated and perplexing than computer language misfeatures that need to be considered during an implementation of those ideas

The problem was generally solved in this thread using arithmetic, that it can be solved another way entirely likely would not occur to most C programmers precisely because of how the programming language influences one's thinking. I only devised the solution when struggling to get an answer using F#, after beginning to see the input sequence as something we are incrementally reducing, I began to see it as a digit replacement problem and not an arithmetic problem.

Had I not been working with an alien (to all intents and purposes back then) language I would have implemented it as most here did.

The bottom line is that I very much doubt a team of hardware engineers would design a language like C if they were afforded the opportunity to really think about it and specify the goals and requirements of a true engineers MCU programming language. C simply did not emerge from such an origin, it was not designed "for engineers" it was not designed for "abstracting hardware fundamentals" it was designed for an ability to create a compiler quickly and cheaply with minimal effort by the compiler developer, that is the goal that it served.

 

I don't disagree with much of what you say here. The impetus for the exercise was this comment from nsaspook:

The bottom line is that I very much doubt a team of hardware engineers would design a language like C if they were afforded the opportunity to really think about it and specify the goals and requirements of a true engineers MCU programming language. C simply did not emerge from such an origin, it was not designed "for engineers" it was not designed for "abstracting hardware fundamentals" it was designed for an ability to create a compiler quickly and cheaply with minimal effort by the compiler developer, that is the goal that it served.

Teams of hardware engineers have better things to do than to design computer languages. We take an ancient language like C, and do useful work with it, today, then move on to the next job.

A team of hardware engineers and computer architects would design the hardware to support a native machine language like that was used on the early multics and PDP machines. Computer programmers working closely with that team designed a series of languages (BCPL/B predecessors to C) to program that hardware. On the PDP-11, where many C expressions mapped (as they would with most processor) to a few instructions it was quick and easy to fashion a close to the hardware language like C but it would have been foolish to do otherwise when a design consideration, out of many, was make it easy to understand how the language's abstract machine maps to the underlying physical machine for designing the low-level features needed for a OS.

 

Teams of hardware engineers have better things to do than to design computer languages.

That's a provable statement I take it? You speak for all those who write software and firmware on MCUs? You know what everybody else wants? You know what's best for everybody else?

We take an ancient language like C, and do useful work with it, today, then move on to the next job.

What bearing does that have on the theme of this thread?

A team of hardware engineers and computer architects would design the hardware to support a native machine language like that was used on the early multics and PDP machines. Computer programmers working closely with that team designed a series of languages (BCPL/B predecessors to C) to program that hardware. On the PDP-11, where many C expressions mapped (as they would with most processor) to a few instructions it was quick and easy to fashion a close to the hardware language like C but it would have been foolish to do otherwise when a design consideration, out of many, was make it easy to understand how the language's abstract machine maps to the underlying physical machine for designing the low-level features needed for a OS.

Well first that's inaccurate and second it has nothing to do with MCUs, as you well know. C never ever abstracted buses, interrupts, stacks, UARTs, Timers, SPI, AD/DA converters, so what are you talking about when you claim "how the language's abstract machine maps to the underlying physical machine" when C predates all microprocessors and all microcontrollers?

Additionally some of my concerns about C are absolutely nothing to do with hardware but with extensibility and intelligibility. Extensibility of a language lies within the domain of programming language theory not electronics.

But again. the relevance escapes me. This thread is simply discussing the kinds of language features that MCU programmers might find useful, helpful productive etc. in a language specifically designed for writing code for those devices.

You are obviously content to trudge along with C in your work, and that's absolutely fine with me, but perpetually objecting to just the idea of improving a programming language is bizarre, if you have no interest and nothing to contribute, why keep posting in the thread? it really makes no sense.

I mean if the developers of C had themselves seen things through your eyes, they'd have opted to press on using an ancient language like COBOL and never even created C !

 

That's a provable statement I take it?

Sure, ask my manager. I keep posting to keep the thread in the world of practical reality of people with actual embedded experience. People who actually design MCU hardware, people who actually design PCB's for those systems, people who actually program rev 0.1 software on that completed rev. 0.1 board and fix it with the next rev using C or some other language. I'm not content with C, I use it as a tool.

What's bizarre?

RANT on
You really have no idea how sick we are of software guys adding features to help us.
RANT off

 

Sure, ask my manager. I keep posting to keep the thread in the world of practical reality of people with actual embedded experience. People who actually design MCU hardware, people who actually design PCB's for those systems, people who actually program rev 0.1 software on that completed rev. 0.1 board and fix it with the next rev using C or some other language. I'm not content with C, I use it as a tool.

What's bizarre?

What's bizarre is you apparently have nothing but contempt for the suggestion that a programming language could be improved or replaced and spend time submitting post after post ridiculing the idea. We get it, you hate the idea of change, of improvement, but many of us do not so let the subject be discussed, is that asking too much?

 

The problem was generally solved in this thread using arithmetic, that it can be solved another way entirely likely would not occur to most C programmers precisely because of how the programming language influences one's thinking.

I still disagree with this claim. You are saying that C programmers aren't going to come up with a non-arithmetic-based solution as a direct result of how that programming language influences their thinking. But then how do you explain that an-oh-so-slight variation of this problem that is routinely posed to most kids in elementary school long before they ever work with ANY programming language almost always leads to the same type of arithmetic-based algorithm> I'm speaking about the means of determining if a nonzero number is divisible by 9: Sum up all of the digits in the number and if that number is divisible by 9, then the original number is. This is naturally recursive and so they can keep repeating this process until are down to a single digit result and the original number is divisible by 9 if and only if the result is 9. For your claim to be valid, those kids must be being influenced by a programming language that not only have they never seen, but when they don't know about the very concept of computer programs or programming languages in the first place.

 

I still disagree with this claim. You are saying that C programmers aren't going to come up with a non-arithmetic-based solution as a direct result of how that programming language influences their thinking. But then how do you explain that an-oh-so-slight variation of this problem that is routinely posed to most kids in elementary school long before they ever work with ANY programming language almost always leads to the same type of arithmetic-based algorithm> I'm speaking about the means of determining if a nonzero number is divisible by 9: Sum up all of the digits in the number and if that number is divisible by 9, then the original number is. This is naturally recursive and so they can keep repeating this process until are down to a single digit result and the original number is divisible by 9 if and only if the result is 9. For your claim to be valid, those kids must be being influenced by a programming language that not only have they never seen, but when they don't know about the very concept of computer programs or programming languages in the first place.

I actually more or less agree, my point isn't that C is the cause of the solution, it is that it subliminally restricts the kind of solution. We traditionally perceive the problem as an arithmetic problem, we write a solution in C largely reflecting that perception. The point is that using a different language often leads to quite different solutions, a different language can lead to quite different ways of perceiving the problem and consequentially lead to solutions that very likely would not routinely emerge in (say) C.

Now of course the differences between functional languages and imperative languages is rather large, but the point is demonstrated by this example, I think it is anyway, there are lots of examples, just stroll over to Hacker Rank or somewhere and look at some of the problems.

When I was exploring F# I initially devised a solution like many of the C solution here, I divided and so on, it was habitual to start off as I did. Only later after seeing how ugly it looked in F# did I begin to think about it differently.

C programmers think (largely subconsciously) in terms of null terminated strings that are in buffers one byte longer than the text, they think in terms of pre/post increment/decrement, they think in terms of global state, they think in terms of ignoring function return values, or of expressions and operators that modify their operands, much of this is implicit, subliminal but it is attributable to the language.

I'm a huge fan of Edward de Bono, the "inventor" of the term lateral thinking, he has spoken and written extensively about thus kind of thing.

He's argued for years that we often - subconsciously - make decisions and assumptions very early on, about a problem that are not true and then have the effect of either limiting the kind of solution or even sometimes not being able to find a solution.

He has many examples, for example the match box problem. He shows a person four matchboxes all setup so each is touching three others, then he shows them an arrangement where each one is touching only two others, then has asks them to arrange them so that each box is touching only one other box, in formal tests and trials people do often stare for ages, stumped, unable to solve it.

Professional problem solvers like most of the people here, can benefit from understanding some of these principles, they very way we think often inhibits progress.

 

Some more interesting things to consider in a hardware oriented language is the well known read-modify-write (compare and swap etc) concept and the write-one-to-clear concept.

These could be elevated to the status of first class language concepts, perhaps as attributes on a declaration or possibly a distinct data type, somewhat like "volatile" is used to avoid caching and soon.

 

RANT on
You really have no idea how sick we are of software guys adding features to help us.
RANT off

Again you speak collectively of a "we" and an "us" but this is just a forum for people to converse, share ideas, ask questions, why the heavy emotional baggage?

I've designed and developed working compilers from the ground up, I have genuine, extensive real world experience of that software problem domain and I'm truly interested in the mapping between programming language and MCU hardware. I also formally studied electronics, telecommunications, radio, microprocessors back in the very early 1980s though I never worked professionally in electronics much to my disappointment, but life is what it is.

I've also had stuff published in reputable publications, I've worked in software development in various capacities for some 40+ years, it is my profession and my craft and I'm very very good at it.

Am I a professional MCU developer? no, am I a professional hardware engineer? no, but that doesn't matter, all that matters is the strength or weakness of my arguments, so focus on them and not me please.

Basically I do not care what you are "sick off" this is no place for such language, complain and whine and grumble if you want, but I will discuss what I want to discuss.

 

If Covid has taught me anything, it's: "Never trust the experts."

 

Support constant execution time directives - see here.

 

OK so I have a draft initial list of bullet points that a new hardware oriented language could consider based on this thread and a few others:

1. No reserved words (new keywords can be added without breaking backward compatibility)
2. No forward declarations needed "in file"
3. Use braces for block delimiters
4. Support pointers
5. Support bit data types
6. Support structures
7. Support string data types
8. No support or affinity with OO, inheritance, interfaces and so on
9. Supports namespaces
10. Label variables, computed goto
11. Bit shifts, rotates etc.
12. Support constant execution time capability
13. Support method overloading
14. Support alignment, padding and packing attributes
15. Support some kind of "endian" specifier
16. Support nested methods
17. Support a "nop" feature to literally embed "nop" instructions -> nop(12); // insert 12 literal nops
18. Distinguish functions and procedures
19. Cannot invoke a function other than as an expression
20. Cannot invoke a procedure other than with "call"
21. Support decimal fixed point data type
22. Support BCD data type (if not the same as decimal)
23. Support any array dimensionality
24. Support dynamic array declarations
25. Support sparse arrays
26. Support ability to add new symbolic operators without breaking backward compatibility
27. Consider support for yielding in addition to returning
28. Consider support for coroutines
29. Consider language keywords/constructs for common hardware mechanisms like ADC, timers etc.
30. Consider synchronization and fence abstractions
31. Consider a "portable" keyword which validates function source code for any possible non-portable content.
32. Support a "write to set" concept, a way to represent that say as an attribute.
33. Possibly expose "bit bands" linguistically, if supported in some target.

These are just ideals, nice to have goals, not saying each is really needed or that we know how to implement them etc, just a very vague idealized list, no analysis of feasibility or anything.