pic & avr

Microchip en Atmel zijn beide grote bedrijven, die veel geld steken in vernieuwing en ontwikkeling, en naar alle waarschijnlijkheid houden ze het beide nog wel een flinke tijd vol.

Als je nog lang verkrijgbare chips wilt kun je het beste voor een gangbare chip uit de meest moderne serie kiezen, die heeft het meeste kans nog lang geproduceerd te worden.

Dinosuarus nemen, de 8051. die wordt door verschillende fabrikanten gebouwd. Kans dat die ooit niet meer leverbaar is is daardoor erg klein. Stopt de ene fabrikant er mee, zijn er nog genoeg andere over.

Microchip PIC wordt alleen door microchip gebouwd. wel is het zo dat microchip nog nooit een chip heeft uitgefaseerd en niet meer kan leveren.

Atmel AVR wordt alleen door Atmel gebouwd. Atmel heeft al wel chips uitgefaseerd die dan ook niet meer geleverd kunnen worden.

Lang verkrijgbare 'identieke' meuk: neem microchip. Accepteer de vele nadelen.

Die overweging is voor jou niet zo interessant (je hebt de source). Atmel is een meester in devices compatible houden. Nieuw model? Rebuild voor het nieuwe model en gaan. *Alle* defaults zijn zo gekozen dat ze compatible zijn met 'zoals het vroeger was'. Verder zijn er uitstekende migration notes, met name voor verbeteringen in de nieuwe hardware.

Andere overweging: neem een 8051 core. Kost niet (veel) meer (zeker niet met de prijzen van microchip). Zeker veel tools voor verkrijgbaar en je hangt niet aan 1 fabrikant. Qua architectuur is dat micochip spul hoe dan ook om te janken (zwaaaar verouderd en onhandig), 8051 heeft daar ook wat nadelen. Groot voordeel is dat het ding inmiddels zo uitgekauwd is dat het in vele, vele verschijningsvormen te vinden is. Van 'bare' tot 'loaded with interfaces', net wat je zoekt.

Laatste overweging: programmeertaal. AVRs zijn uitermate geschikt voor C. 8051s wat minder (C is redelijk stack-oriented, een 8051 heeft nauwelijks stack). Prima mee te werken, maar het is wel een belangrijk gegeven waar je zeker rekening mee moet houden. Begin niet aan taaltjes als basic. Leuk voor wat gerommel in de marge, niet voor serieus werk. Veel te veel shitload aan onnodige functionaliteit.

Support: eigenlijk van, Atmel (AVR, 8051) als SiLabs (8051 core) nooit nodig gehad. Was online te vinden. Microchip kwam niet verder dan 'dat is nou eenmaal zo'.

Als het om support gaat, kun je waarschijnlijk het beste Microchip kiezen. Daar krijg je in ieder geval antwoord op support vragen. (en meestal nog zinnige antwoorden ook...) Bij Atmel en Silabs heb ik nog nooit een zinvol antwoord op supportvragen mogen krijgen. (soms zelfs helemaal geen reply)

Welke taal je gebruikt hangt van de applicatie af. Basic of C maken niet veel verschil. 't Hangt tenslotte van de compiler (en de programmeur) af of een programma brak wordt of niet...

Een slecht programma kun je in elke taal schrijven.

De timing is wel aardig. Zie hier

oke dank jullie wel voor alle informatie, ik heb besloten om voor atmel te gaan, omdat ze de chips compatible houden en ik c programmeer dus stack-oriented werk. (en natuurlijk omdat ik ze ook fijn vind werken).

dank u allen voor de snelle reacties;)

Als je een behoorlijke compiler wilt, neem gcc. Die van imagecraft is beter, maar kost ook wat. Geen idee hoe spannend je code is wat size / timing betreft. Heb met beide compilers gewerkt, gcc voldoet doorgaans prima. Als het 'tricky' wordt (wat timing betreft), wordt het doorgaans toch (write-only)assembly...

Op 25 mei 2011 11:29:19 schreef Arco:
Daar krijg je in ieder geval antwoord op support vragen. (en meestal nog zinnige antwoorden ook...) Bij Atmel en Silabs heb ik nog nooit een zinvol antwoord op supportvragen mogen krijgen. (soms zelfs helemaal geen reply).

Ik heb een keer problemen gehad met een AVR can bootloader die ik niet werkend kreeg. Van de support kreeg ik wel zinnig antwoord en uiteindelijk hebben ze zelfs gratis 2 usb-can converters van ixxat opgestuurd. Het is volgens mij maar net welke persoon aan de andere kant van de lijn zit.

Op 25 mei 2011 11:19:44 schreef EricP:
Begin niet aan taaltjes als basic. Leuk voor wat gerommel in de marge, niet voor serieus werk. Veel te veel shitload aan onnodige functionaliteit.

Onzin, Basic is al jaren volwassen.

Kom nou toch Henry... Basic is by design niet handig (voor serieus gebruik). Dat heeft niks met volwassen te maken, gewoon met de structuur van de taal. Gaat ook nooit meer beter worden, als het beter wordt, heet het geen basic meer...

Vergelijk het met Pascal (al is dat wat minder rampzalig). Erg handig voor 'academisch gebruik' (goed inzicht in wat je doet, een =≠=: om maar wat te noemen). Maar echt handig (zeker op een μC)? Nee...

Ook dat is onzin, ook basic kan gestructureerd zijn. En dan heet het nog steeds basic en geen C, al wordt de verschillen ietsje kleiner. Kijk eens naar MikroBasic en Swordfish.

Verder maakt het echt niet uit wat je voor tools gebruikt, garbage in = garbage out.

Basic wordt steeds gestructureerder. Ik gebruik ook Mikrobasic Pro.
Als je er geen fatsoenlijk programma mee kunt maken moet je niet de compiler de schuld geven...
Met C is het vaak veel erger. Complexe statements zijn bijna niet te volgen. (zeker niet zonder commentaar.)
Ze noemen het ook niet voor niets een WORN language... (Write Once Read Never)

Teneinde de gemoederen wat te verhittenbedaren, mijn persoonlijk idee wat programmeertalen voor een µC betreft:

Wil je het onderste uit de kan halen, gebruik dan assembly (of naakte machinecode, zoals ik ooit begonnen ben met een Z80).

C heeft mijn voorkeur. Het sluit nauw aan bij assembly, maar neemt heel wat omslachtig werk uit je handen. Met linked lists, in combinatie met malloc, kan je beter niet beginnen...

Van basic heb ik een ingewortelde weerzin. Dat is te danken aan ene mijnheer Sinclair, en de onbruikbare basic-interpreter v/d ZX81 (vandaar de machinecode, die op dat ding 1000 maal sneller liep). Noem het gerust een trauma.
Maar er is meer. Als ik in C programmeer, dan weet ik ongeveer wat de compiler daar van gaat maken. Ik kan me moeilijk voorstellen, dat zulks voor basic ook het geval is (maar ik kan me vergissen!). Meer zelfs, ik heb de indruk dat de doorsnee basic-adept er helemaal geen idee van heeft wat er werkelijk gebeurt - en zelfs de datasheet v/d µC nog nooit onder ogen heeft gehad. Maar ook hier geldt: ik kan me vergissen.

Ook dat is onzin, ook basic kan gestructureerd zijn.

Dat de taal brak is zegt niks over gestructreerd of niet. Assembly dwingt (in die context) niks af en kan vreselijk gestructureerd zijn.

En dan heet het nog steeds basic en geen C, al wordt de verschillen ietsje kleiner. Kijk eens naar MikroBasic en Swordfish.

Dat heeft er niks mee te maken. De TAAL is gewoon een ramp. Of je er gestructureerd mee werkt of niet, zegt iets over de gebruiker, niet over de TAAL.

Verder maakt het echt niet uit wat je voor tools gebruikt

Om de donder wel. Basic (om een voorbeeld te noemen, maar het is lang niet het enige voorbeeld) matched nou eenmaal niet op een controller. En dan doel ik niet op die crompilers die ook nog eens een vorm van P-code gebruiken en een halve interpreter laten runnen. De taal heeft geen enkele relatie met de hardware. Toegegeven, C heeft ook enigzins last van (bijvoorbeeld) een runtime lib, maar die is erg klein en bevat eigenlijk nauwelijks iets (wat niet weg neemt dat je een berg 'shit' mee kan nemen door 'onhandige' constructies te gebruiken.) Wat dat betreft is C op een 8051 net zoiets kroms. Door allerlei trucen 'werkt' het wel, maar het blijft behelpen (alhoewel de compiler bouwers wel steeds slimmer worden in die trucen). Gebruik daar iets als PL/M voor. Dat matched al een stuk beter.

Pros formuleert het precies juist... Jaren lang Basic geprogrammeerd (was de standaard taal op school) en liep toen al tegen de beperkingen (in zowel 'kan niet' als in 'wat wordt dit nou weer voor een bullshit'). Dat heet niks met gestructureerd of niet te maken, de TAAL matched gewoon niet. Pascal heeft hetzelfde probleem. Leuk om gestructureerd te leren werken (het dwingt het van nature af, al kun je er natuurlijk ook bagger constructies in verzinnen), maar het 'past' doorgaans aan alle kanten niet op waar het op draait.

Op 25 mei 2011 19:33:12 schreef Henry S.:
Verder maakt het echt niet uit wat je voor tools gebruikt, garbage in = garbage out.

Ja, da's altijd. Maar diamonds in -> garbage out kan ook....

Op 25 mei 2011 20:50:53 schreef pros:
Wil je het onderste uit de kan halen, gebruik dan assembly (of naakte machinecode, zoals ik ooit begonnen ben met een Z80).

Assembly is bijna nooit nodig. Dwz... er is vrijwel altijd 1 routine die het gros van de CPUtijd op zich neemt. DIE kan je dan naar assembly vertalen als de C-code te langzaam blijkt.

[Bericht gewijzigd door rew op woensdag 25 mei 2011 21:25:46 (45%)]

Op 25 mei 2011 21:14:48 schreef rew:
[...]
Ja, da's altijd. Maar diamonds in -> garbage out kan ook....

Jammer dat de andere kant op nog steeds niet werkt. shit in, diamonds out

Op 25 mei 2011 20:50:53 schreef pros:
Van basic heb ik een ingewortelde weerzin. Dat is te danken aan ene mijnheer Sinclair, en de onbruikbare basic-interpreter v/d ZX81 (vandaar de machinecode, die op dat ding 1000 maal sneller liep). Noem het gerust een trauma.

Heel herkenbaar, de C64 met een wanprodukt van Bill Gates, CBM basic v2.0. Zeer traag dus snel 6502 assembly geleerd, kort daarna kwamen daar Pascal en 6802 assembly bij. Veel later AmigaBasic (alweer van MS), Blitz, C, 68000 assembly, Oberon en Modula-2. Daarna heeft het jaren stilgelegen en Proton+ Picbasic opgepikt. Dat bevalt me goed en voor grotere structurele dingen gebruik ik wel eens Swordfish, maar wegens tijdgebrek staat dit op zeer laag pitje.

Maar er is meer. Als ik in C programmeer, dan weet ik ongeveer wat de compiler daar van gaat maken. Ik kan me moeilijk voorstellen, dat zulks voor basic ook het geval is (maar ik kan me vergissen!).

In zekere zin klopt dat, maar ook in basic heb je de datasheet nodig, bijv registerinstelling gaan deels direkt in inline assembly. Doe je dat niet dan beperk je jezelf erg. Op het forum zie je dit bijv in topics over het overstappen naar een andere, complexere controller. Nog geen datasheet gezien en alleen wat knip&plakerk vanaf picbasic.nl gedaan. Tja... voor elke taal geldt dat je er tijd in moet steken.

Maar aan de andere kant... C is vaak obfuscated, net of C-programmeurs dat met opzet doen.

Oke, waar ging het topic al weer over?
Oh ja, de soort microcontroller... Maakt niets uit, elk type heeft zijn voor- en nadelen. Het is niet zo zwart-wit zoals ericP het voorschotelt.

Op 25 mei 2011 21:14:07 schreef EricP:
Dat de taal brak is zegt niks over gestructreerd of niet. Assembly dwingt (in die context) niks af en kan vreselijk gestructureerd zijn.[...]Dat heeft er niks mee te maken. De TAAL is gewoon een ramp. Of je er gestructureerd mee werkt of niet, zegt iets over de gebruiker, niet over de TAAL.

Wanneer heb jij voor het laatst basic serieus bekeken, je spreekt over vergaande 'glorie'... En wat bedoel je met 'brak' (niet met goto/gosub return aankomen)?

Op 25 mei 2011 21:32:15 schreef Henry S.:
Oke, waar ging het topic al weer over?
Oh ja, de soort microcontroller... Maakt niets uit, elk type heeft zijn voor- en nadelen. Het is niet zo zwart-wit zoals ericP het voorschotelt.

Noem nou eens 1 voordeel van Microchip? Ik lees hier al een paar jaren mee, maar ik heb nog geen ENKEL voordeel van zo'n ding kunnen vinden... Behalve wat vage redenaties 'dat is handig' terwijl elke controller uit hetzelfde tijdperk dat minstens ook (en doorgaans beter) kan... niks. Zoveel periferals? Maxim heeft er meer. Snel? SiLabs heeft veel snellere chippies (voor minder geld). Goedkoop? Ja, als je sampled (om die paar euro voor de hobby uit te sparen). Nou , vooruit... Ze hebben nog steeds controllertjes die oude meuk kunnen draaien. Boeiend. Recompile. Klaar. (en als je de source niet meer hebt, zegt dat meer over de manier waarop je ontwikkelt dan over de leverancier).

Wanneer heb jij voor het laatst basic serieus bekeken, je spreekt over vergaande 'glorie'... En wat bedoel je met 'brak'?

Dat heb ik nou al een paar keer omschreven. Het matched helemaal nergens op. PL/M matched goed op een 8051. C doet dat vrij redelijk op een AVR (en voor zover ik weet op een ARM, maar mijn ervaring is daar redelijk beperkt). Voor wat gepiel in de marge zal het best wel wat kunnen. Precies zoals pros beschrijft... Geen flauw idee wat die compiler er van gaat maken (terwijl je dat als je een beetje C kennis hebt doorgaans op je klompen aan kan voelen). Vaag gedoe met variabelen... Laat maar. En nogmaals, C is niet perfect. Taal bevat te weinig info voor de compiler (en is in die zin dus ook te generiek) om er het maximale uit te halen. En om antwoord te geven op je vraag: een tijdje terug wel eens wat met Bascom geprobeerd (op verzoek... was zelf nooit op het idee gekomen). Snel de hoek weer ingemieterd. Blijft Basic. Blijft niet matchen op de hardware. Mijn kennismaking met Basic was trouwens op een TI99/4A. Snel overgestapt op BBC basic (die C64 en consorten links laten liggen... alleen leuk als je alles in assembly deed...). Die basic was de hardware vooruit. Maar ook daar kon je er geen pijl op trekken wat er nou eigenlijk gebeurde. Dus ook daar snel over naar assembly - was trouwens een groot verschil, basic draaide in die tijd nog interpreted en niet compiled. Daarna kennis gemaakt met business-basic, quick basic en turbo basic. Nooit enthousiast van geworden (quick basic had nog wat bekende M$ trekjes... spontane crashes zo nu en dan... enorme runtime lib...). Pascal was minder erg door gebruik van inline assembly (kon in die tijd niet of nauwelijks met basic), maar da's eigenlijk 'de achterdeur uit'

Overigens is dat nog een nadeel van Basic (en dat geld in beperkte mate ook voor C!): je hangt al snel aan een compiler leverancier. Als die er mee stopt, ben je f*cked. Voordeel van C is dan nog dat het enigszins portable kan zijn (maar dat hoeft zeker niet).

Amigabasic was idd. ook een ramp. Heb het maar kortstondig uitgeprobeerd, en al snel op 68000/68030 assembly overgestapt. En tenslotte maar op C...

Op 25 mei 2011 21:48:30 schreef EricP:
Noem nou eens 1 voordeel van Microchip?

Support!

Dat heb ik nou al een paar keer omschreven. Het matched helemaal nergens op. PL/M matched goed op een 8051. C doet dat vrij redelijk op een AVR (en voor zover ik weet op een ARM, maar mijn ervaring is daar redelijk beperkt). Voor wat gepiel in de marge zal het best wel wat kunnen. Precies zoals pros beschrijft... Geen flauw idee wat die compiler er van gaat maken (terwijl je dat als je een beetje C kennis hebt doorgaans op je klompen aan kan voelen). Vaag gedoe met variabelen... Laat maar.

free_electron heeft eens wat basiccompilers wat compilerpeformance betreft onder de loep gelegt. De MikroE familie kwam niet zo goed uit de bus vanwege het tussencompileren, maar Proton+ en Swordfish zaten in zijn opinie heel dicht op de hardware/assembly.

En nogmaals, C is niet perfect. Taal bevat te weinig info voor de compiler (en is in die zin dus ook te generiek) om er het maximale uit te halen.

Is ook mijn mening sinds gebruik van C op de Amiga, maar ja alles was gedocumenteerd in C.

En om antwoord te geven op je vraag: een tijdje terug wel eens wat met Bascom geprobeerd (op verzoek... was zelf nooit op het idee gekomen).

Bascom heeft me ook nooit gelokt, ik heb het wel eens bekeken, maar ik mis wat.

Op 25 mei 2011 21:59:53 schreef Henry S.:
[...]
Support!

Zoals gezegd... Nooit wat zinnigs uitgekomen toen ik nog wel eens wat met microchip spul probeerde (snel mee gestopt overigens). Van andere leveranciers (in deze hoek) nooit support nodig gehad - was voldoende gedocumenteerd, al dan niet door de fabrikant zelf (ik geef toe... wel wat aan community te danken). Geen ervaring met die mannen dus...[edit... iets te snel met klikken]

free_electron heeft eens wat basiccompilers wat compilerpeformance betreft onder de loep gelegt. De MikroE familie kwam niet zo goed uit de bus vanwege het tussencompileren, maar Proton+ en Swordfish zaten in zijn opinie heel dicht op de hardware/assembly.

Wat hardware betreft, heb ik een bijzonder hoge pet op van f_e. Wat software betreft... Wat minder...

Er zijn statements die gewoon niet 'dicht op de hardware' kunnen zitten. In C is printf zo'n draak. Basic heeft er nog een trosje meer van... Precies zoals ik al omschreef...

[Bericht gewijzigd door EricP op woensdag 25 mei 2011 22:09:17 (39%)]

Op 25 mei 2011 19:29:16 schreef EricP:
Kom nou toch Henry... Basic is by design niet handig

dus jij leest liever een nest cryptische symoblen dan klare duidelijk keywords ?

ik niet ! en al dat haakjes en semicolon gedoe , parsers die niet begrijpen uit de constext of het nu om ene toekenning of een vergelijking gaat ... C is gewoon iets wat in elkaar geflansd is. Over basic is nagedacht !

De doelstelling van basic was van meet af aan : het moet een voudig te lezen en schrijven zijn.

C is niks meer dan een pre-processor om machinetaal voor luiaards te schijten en gemaakt is door luiaards. In plaats van een compiler te bouwen met wat context sensitivity hebben ze gewoon wat symbolen gedefineerd. De eerste c compiler deed eigenlijk niks anders dan find an replace...
( nu is dat anders natuurlijk met optimizing compilers maar de eerste 'compiler' was niks anders dan een preprocessor. als er '=' is het een toekenning, als er == staat is het vergelijking. als er staat 'if a=b' dan wordt dat 'als b toegekend aan a'. Op wat slaat dat nu ? dat is koeterwaals ! als die shitcompiler 2 seconden had nagedacht (ene extra decision tree) dan kon hij weten dat hij bezig is met een if-then-else clause en het om een vergelijking gaat en niet om een toekenning. ).
Bovendien heeft c veel te veel onduidelijkheden en is er veel te veel verschil over hoe dingen geimplementeerd worden tussen compilers.

In deze discussie is er tot nu toe 1 punt over het hoofd gezien : met name een werkbare IDE !
Ik moet nog de eerste IDE zien voor microcontrollers die in de buurt komt van wat Visual Studio doet in VB of C# ( ik heb het nu over autocompletion, reference resolution etc , en kom niet af met 'in eclipse kan je met ctrl-spatie ook die lijst oproepen. vingerkamp inducerende ctrl-shift-tilde-linkergroteteeninrechteroor zijn bij mij samen met het membraan toetsenbord van de zx81 in de vuilbak gevlogen. ik wil gewoon terwijl ik typ na het . of spatie dat vensterke krijgen zonder daarbij op speciale toetsencombinaties te moeten rammen.)

Ik heb tot nu toe met success een aantal malen de swordfisch compiler gebruikt op PIC ( 2550's en 4550's)
Die swordfisch compiler maakt echte machienetaal. MikroE daarentegen is een draak die steunt op een enorme voorgekauwde runtime library. dat ding is bijna een virtuele machine. Proton is dan weer een ouwbollige basic die geen benul heeft van functies en subroutines.

in swordfish kan je mooi overlayed code maken, het ding heeft zelfs operator overloading en leunt op sommige punten heel sterk aan bij een object oriented taal met als enig punt dat je geen objecten at runtime kan aanmaken ( iets wat op systeempjes met limited resources zoals pic en avr toch absolute waanzin zou zijn )

een ander punt is integratie met een debugger. We gaan anno 2001 ons toch nie tmeer gaan behelpen door overal print statements tussen te gooien om te debuggen. dat vreet code en data space en het vertoord enorm de echte speed van de applicatie. het zou niet de eerste keer zijn dat, na het verwijderen van de print statements, er race condities optreden waardoor het programma niet meer werkt...

zorg dat je IDE kan source tracen en single steppen en de mogelijkheid heeft om watchpoints te zetten op variabelen.

eendert welke omgeving die dat NIET kan is zijn geld niet waard ( ook al is ze gratis ! )

Dat is wat ik er van denk. mijn taak is ene blok hardware te bouwen en te debuggen. een stuk van die hardware staat onder controle van een 'programma'. het laatste wat ik moet hebben is een programmeertaal en ontwikkelomgeving die constant 'tegenwringen'. ik heb daar geen tijd voor. Brand dat ledje nu al of niet ? oh wacht ik moet eerst nog eerst 500 semicolons typen en verifieren dat de compiler gesnapt heeft wanneer het om een toekenning of een vergelijking gaat... laat maar voor mij hoeft het niet. kzal wel iets pakken wat iets intelligenter is en meer gebruiksvriendelijk

( op PC kan er voor mij NIKS op tegen VB qua userfriendlyness. je kan midden in de run stoppen , de execution pointer aanpassen , commandos invoegen ,verwijderen en dan doodleuk 'continue' doen. Er is niks productiever dan een interactieve debug sessie waarbij je aan het end van de run de correcte code hebt. in 'c' is het niks anders dan edit-compile-start-stop-edit-compile-fix typo-compile-fix type-compile-run-crash-edit-compile-fix typo-compile at infinium.

Ha Heerlijk!
We hebben weer eens een stammenstrijd over programmeertalen.
Wel treurig om de huidige generatie basic's te vergelijken met die van de ZX81 van notabene 30 jaar geleden. Er is in de tussentijd echt wel wat veranderd hoor!
Opmerkingen dat een taal niet 'past' op een uC kan ik niet volgen....wat is dan 'passen', wanneer 'past' het wel?

Ik zie dus ook niet in waarom Pascal niet 'past' en C wel.
Het dringt blijkbaar maar matig tot de grijze cellen door dat de basis van deze programmeertalen nooit was bedoeld voor uC's. Dus C als basistaal (nou ja, spraakgebrek) heeft niets met uC's, net zo min als Pascal. Door de machine specifieke uitbreidingen (libraries) wordt het toepasbaar.

De argumenten van free snijden wel hout. De ontwikkelomgeving is voor een groot deel bepalend voor het gemak waarmee je werkt. Overigens heeft Proton wel degelijk subroutines, maar dat terzijde.
De voordelen die hij noemt van VB zie ik wel, ik houd alleen niet van al dat impliciete gedoe in VB. Geef mij maar Delphi.
Maar ja, zo heeft ieder z'n gekte.

Op 26 mei 2011 00:07:50 schreef hadv:
Opmerkingen dat een taal niet 'past' op een uC kan ik niet volgen....wat is dan 'passen', wanneer 'past' het wel?

in mijn context : C past niet op niet register gebaseerde systemen.
C is ontwikkeld voor een processorarchitectuur die op registers stoelt ( PDP ). de meeste micrcontrollertjes werken zo NIET.

ook het concept van we hebben een stack en heap ... in 128 bytes ? je bent knetter !

En die verrekte opstartcode van 'c'. de meeste compilers bakken een hoop startcode waarin ze variabelen en constanten initialiseren. dat is stomweg onnozel.waarom moet dat nu uit rom gehaald worden om ram te vreten. laat dat staan en gebruik de juiste access call.

vandaar de noodzaak aan talen die eigenlijk op dergelijke dingen gemaakt zijn. Pl/M is daar het schoolvoorbeeld van. Gary Kildall ( de vader van CP/M ) heeft die taal gemaakt voor de eerste 8 bit Harvard machienes van intel zoals de 8008, 8048 en 8051. later is die uitgebreid naar de 8086, 8096 i860 en i960.
PL/M heeft geen 'stack' heap of runtime lib. Dat ding spuugt vanuit je source direct machinetaal. en dat is haast een 1:1 translatie.
die compiler is intelligent en bouwt een traced memory map op. het ding weet wanneer er wat in gebruik is en kan uitvlooien wat er overlayable is en wat niet.