Leuke tijd! Assembler programmeren! Mijn voorkeur lag bij de Motorola's 6802, 6809 etc.

Haha, ja, assembly FTW :)

Ik doe zelf vrij veel reverse engineering en dat is ervaring met het schrijven van assembly
echt wel een pre. I guess dat dat dan weer een voordeel is wat wat "oude" (based op je
opmerking over 6802) "rotten" dan weer hebben op de youngters :>

#int80h

Het is inmiddels niet meer helemaal mijn vakgebied maar die kennis van vroeger komt ook bij hogere programmeertalen van pas. Ik heb nog hexadecimale code op een Eurocom 1 zitten inkloppen https://www.mikrocontroller.net/topic/285693 wat echt leerzaam was.

Ik zal wel weer gebanned worden want over het algemeen hebben ze weinig humor bij security.nl
maar deze foto's zijn voor een computer nurd pure porno.. ;)

Zelf ook assembler gedaan, vrij recent zelfs weer nog eens, en ZOMGWTFBBQ is de 8086 toch een onding.

En dat karaktertrekje is er ook in latere modelletjes gewoon niet meer uitgegaan.

Tegen die tijd was er om te beginnen op duitse TV een leerzame serie over 74xx logic hardware.
Mijn eerste zelfgebouwde "fietscomputer" (eigenlijk alleen snelheidsmeter) mee gebouwd.
Het ding leidde de snelheid af van de frequentie van de wisselspanning van de dynamo en werd er ook door gevoed. Kicke!

Vervolgens was er op school een saaie oude tang voor Nederlandse taal.
Voor het eerst moesten we thuis een sollicitatiebrief gaan typen. Moest foutloos en zonder tipp-ex te gebruiken.
Man wat een ramp! Dacht meteen: "hier zou een electronisch corrigeerbare buffer in moeten zitten".
RAM geheugen dus...

In die tijd had je Tandy, die behalve (te) dure apparatuur ook allerlei losse onderdelen verkocht.
k Was er als een kind in de snoepwinkel!
Toevallig niet veel later zag ik daar een grote chip "RAM / I/O" in het rek hangen. (8154, 40-polig)
Koste in die tijd al snel ruim 30 of 40 pietermannen. En dat voor een jonge student...
Maar het was voor mijn gevoel precies wat ik nodig had voor die type-machine buffer.
Dus "kopen dat ding! Hoe het allemaal precies moet, zoek ik later wel uit".
Bleek uit de beknopte meegeleverde schema's dat je er eigenlijk ook een processor en clockgenerator bij moest hebben.
En zo ontstond vanwege een saaie strenge ouwe juf Nederlands mijn eerste zelfgebouwde 8080A systeempje.

En die buffer-typemachine? Bleek toch wat lastig en duur om met allemaal toegevoegd solenoids elektrisch al die toetsen
in te kunnen drukken. Maar ik heb nietemin veel van dit avontuur geleerd en er plezier van gehad.
(sindsdien geen kwaad woord meer over ouwe, saaie, strenge, juffen Nederlands!)

Naakte chips.... oelalaaa! :-D

Het probleem met de 8086 is vooral dat men bij Intel iedere nieuwe chip zodanig wilde maken (zowel voor als na de 8086)
dat ie kon wat de vorige kon plus nog meer. Men is nooit met een blanco vel papier gaan zitten om een nieuwe processor
te ontwerpen, het was altijd het vorige model plus extensies.
Daarvoor vind je alle denkfouten en beslissingen die in 1975 genomen zijn om de boel simpeler te houden ook in latere
modellen weer terug als feature. Zelfs als de reden van de beslissing al lang niet meer aanwezig is.

Dit vindt zijn oorzaak in het feit dat in de begintijd software vaak in assembler geschreven werd en een grote waarde had,
waardoor het voor een klant een groot voordeel was om een processor te kopen die op assembly level (bijna) compatible
was met de voorganger. En in bepaalde gevallen zelfs op machinecode level.

Tegenwoordig wordt alles in hogere programmeertalen geschreven speelt dit helemaal niet meer. Dan is hooguit nog
de binaire compatability nog een issue, bijv klant wil een programma wat hij 10 jaar geleden in binaire vorm gekocht heeft
nog kunnen draaien. Dit speelt in de Windows wereld, niet in de Linux en BSD wereld. Daar wisselt men rustig van
processor architectuur zonder consequenties. De reden dat de Intel 86 architectuur nog steeds voet aan de grond heeft
is dan ook alleen Windows.

U bedoelt te zeggen dat de policy is verschoven van "backwards opcode/instructieset compatibility" naar "software portability"?
Software portability heeft wel een vlucht genomen, maar backwards compatible opcode/instructieset komt ook nog steevast voor. Ook vandaag de dag bestaan er nog hele processor- en microcontrollerfamilies die dezelfde of bijna dezelfde instructieset en architectuur kennen.

De backwards compatibiliteit is wel _de_ reden dat de x86 architectuur leeft, en alle "blanco perfect optimaal volgens de mode van de dag" architecturen weg zijn.

Alle keren dat Intel met een min of meer blanco vel papier ging zitten werd een ramp. i432 , Itanium . Of in elk geval geen of beperkt succes (i860 . i960 ).
De VAX, en de Motorolo 68000 (mn 68020) waren de ultieme CISC architecturen. De 'blanco design ultieme Risc' - Dec Alpha . ook helaas.

Feitelijk heeft het 'allegaartje' aan historie de x86 mogelijk gemaakt om mee te gaan met ontwikkelingen en mogelijkheden van steeds grotere aantallen transistoren - en het toenemende relatieve snelheidsverschil tussen CPU en geheugen.
Features verdwenen niet - maar bepaalde code sequences werden versneld, en andere bleven langzaam(er) - microcoded.
Compilers / code generatie en software pasten zich aan zonder 'big bang' updates.


Bovenstaand is forse onzin. De droom dat alle Linux software 'gewoon gehercompileerd' wordt is een hobbyisten beeld.
Vendors doen dat niet zomaar, en als een architectuur te klein wordt, dan wordt er helemaal niks voor geport/gehercompileerd.
En ja - je moet testen, en er zijn (soms) merkbare verschillen ook een high level code. Des te meer als je praat over 64 vs 32 bit, big endian of little endian, en al helemaal als je een ones-complement vs two-complement CPU eronder legt.

Ontdek zelf dat _zelfs_ Debian gestopt is met bv de Alpha, PA-Risc , MIPS en IA64 (Itanium) ports.
Volgens jouw theorie - Debian is wel een schoolvoorbeeld van 'alleen software met source' - zou dat niet gebeuren.

Leuk verhaal zeg! Ja Tandy, nu je het zegt. Helaas hadden ze bij onze Tandy vestiging weinig verstand van zaken dus gingen we naar andere elektronica zaken.

(ik schreef ook 13:47)
Of om het anders te zeggen : resterende architecturen die nog succesvol bestaan _zijn_ allemaal enorm compatibel met een hele serie oude voorouders.

x86 is er één.
Z arch (IBM mainframe) heeft een familie historie - en backwards compatibiliteit terug tot uiteindelijk system/360 uit 1964 .

De ARM cpu historie gaat ook terug tot 1985 - wat korter dan x86, maar inmiddels respectabel lang.
Ik weet iets minder goed hoe backwards compatibel de ARMs gebleven zijn met hun voorouders, maar het is nu een lange evolutie.

National Semiconductor SC/MP enkel op 5 volt en statische RAM, daar is bij mij alles uit voortgekomen

Weet je, het aantrekkelijke van die losse onderdelen van Tandy was dat er altijd beknopte aanwijzingen en/of specs bij zaten, hetzij gedrukt op de verpakking of op een bijgesloten document dat aan de verpakking zat vastgeniet.
Daar kon je als hobbyist redelijk mee uit de voeten.
Tegenwoordig kan je van alles downloaden maar in die tijd was dat er nog niet.
Ik kwam zo vaak in die winkel dat de man achter de kassa een keer zei "maak jij je zakken maar eens leeg".
Die snapte gewoon niet hoe interessant ik het allemaal vond. (zelfs zonder "de hardware" gratis mee te nemen),
maar dat heb ik hem toen maar even uitgelegd.

Tandy was eigenlijk RadioShack, overgewaaid uit de States.
Ten slotte is Tandy een debakel geworden, o.a. omdat er te weinig vernieuwing was.
https://en.wikipedia.org/wiki/RadioShack

Leuk! SC/MP was mijn vierde microprocessorproject (na 8080A, "COSMOS"- CDP1802 en Z80A)
Ik heb het niet over mijn hart kunnen krijgen om het SC/MP project te slopen of weg te doen. Alles werkt nog.
De processorchip was een bijna-kadootje van een volgende plaatselijke electronicaboer uit de opruiming.

Heb destijds wat zelfbedachte basis- en hulproutines op "houtje-touwtje"-achtige wijze in EPROM weten te branden,
hetgeen het "by byte" machinetaalprogrammeren van sw-projecten moest vergemakkelijken.
Vrij te programmeren mbv 16 hexadecimale toetsen + up- en down-toets voor verhogen/verlagen van het geheugenadres.
Een hulproutine is te kiezen door tegelijk indrukken van één van de hexadecimale toetsen samen met de "up" toets.

Voorziening voor CMOS-geheugenbehoud met goldcap 1 F (ca. 1 jaar bewaartijd zonder te hoeven bijladen) en nog een paar fratsen, zoals de 2K-byte vrij te programmeren low power CMOS RAM, de befaamde 8154 chip, powerdowndetectie met schakeling die razendsnel overschakelt naar RAM-geheugenbehoud en een aantal dipswitch-instellingen waaronder reset, write-protect en toewijzing van adresgebied aan EPROM en RAM.

:) Dat was nog eens een tijd. 'Multitasking' op een single tasking OS (MS en PC DOS) box kreeg je voor elkaar met een TSR programma. Mixed language programming was toen nog een kunst waarbij ik meerdere TSR's heb gemaakt, int12h gehooked, om te kunnen interfacen tussen conventioneel C en Cobol.

Alloceren, dealloceren, bitshiften, pushen en dan niet vergeten weer om te poppen Loads of phun.

Mijn reactie hierop is weg-gemodereerd maar gelukkig blijkt dat ik wel gelijk had: Apple gaat voor de 3e keer over op
een nieuwe processor architectuur voor de Mac. na de 68000, Power-PC, en Intel x86 dus.
Nu gaan we zien hoeveel software er nog is die niet gewoon gehercompileerd kan worden!
En ik denk dat bevestigd gaat worden dat de processor er niet meer toe doet in deze tijd.

Je leest wel echt slecht.
Vrijwel alles _kan_ gehercompileer/geport worden. Dat kost deels tijd, deels moeite - omdat er verschillen (kunnen) zijn die ook in een hogere taal zichtbaar zijn en dus een stukje portering vergen - en minimaal een grondige test.

Als een platform te klein is - neemt men die moeite (=kosten) niet. En soms is de source er niet (meer) , en moet er geëmuleerd worden.
Dat kan ook - en kost dik (factor twee tot factor tien) performance .

Windows is/was ook op ARM beschikbaar - Windows RT, WIndows CE , nu WoA - de (native) software beschikbaarheid was en is vrij marginaal. Als het , in jouw idee niks uit zou maken - dan laten al die Windows software vendoren een stuk markt liggen door hun Windows-x86 product niet ook even voor Windows ARM uit te brengen.
En- wat jij niet hebt uitgelegd - waarom Linux distro's stoppen support van met kleine architecturen als Alpha, PA-Risc - 'gebrek aan source code' is in elk NIET de reden - ik zeg 'alles bij elkaar kost het meer moeite dan alleen de target-arch in de Makefile aanpassen'.

Het _is_ een goede zaak dat er nu een solide ARM desktop platform komt. En het wordt heel boeiend om te zien hoe snel/hoe breed de 'noodzakelijke' applicaties native beschikbaar komen. En in welke mate de trouwe klantenbase van Apple het nog niet beschikbaar zijn van een deel van hun applicaties wil accepteren.

In elk geval is Apple een heel significant platform, dus er is grote druk voor applicatie leveranciers _om_ de moeite te doen om hun applicatie snel native ARM beschikbaar te maken.
En als de beschikbare set van software voldoende groot wordt voor wat de klanten van een Mac verwachten kan het zeker een succes worden.

Wat wel een verschil is met de stappen van 68000-> PowerPC en PowerPC -> x86 : in die gevallen was de 'nieuwe' processor een hele orde van grootte sneller dan het vorige platform.
De software emulatie (Rosetta) was daardoor 'dragelijk' - als in, niet extreem veel langzamer dan op het oude platform.
De overhead van emulatie werd voor een groot deel gecompenseerd door de veel snellere nieuwe CPU.

Dat verschil is er nu niet - of iig niet in die mate - tussen x86 en ARM.

Volgens mij hebben jullie allebei deels gelijk en deels ongelijk. C/C++-code die voor meerdere hardwareplatforms geschreven is bevat de nodige #ifdef's om de verschillen af te handelen. En zelfs als je een applicatie in een behoorlijk ver van de hardware weg-geabstraheerde taal als Python schrijft kan je bijvoorbeeld tegen verschillen aanlopen in hoe paden in het filesysteem zijn opgebouwd, zelfs met ingebouwde hulpmiddelen om dat af te handelen, en bij het verwerken van binaire data kan je ook in zo'n taal met verschillen in woordgroottes en endianness te maken krijgen, om maar een paar dingen te noemen.

Dus natuurlijk is het niet zo dat als iets op het ene platform werkt daarmee gegarandeerd is dat het ook op elk ander platform werkt, er zijn verschillen waar je tegenaan kan lopen en dus moet er getest worden en moeten eventuele problemen opgelost worden met betere generieke of met platformspecifieke code. Maar tegelijkertijd is het ook zo dat de bulk van de code in een hogere programmeertaal daar geen last van heeft omdat dergelijke verschillen geïsoleerd worden op een paar plekken zodat niet overal in de code hetzelfde probleem opnieuw opgelost moet worden.

Dus dat het helemaal niet meer speelt is een overdrijving de ene kant op, en dat het een droom is is een overdrijving de andere kant op. Ik vermoed dat er niets overblijft om het over oneens te zijn als jullie allebei stoppen met oversimplificeren en onderkennen dat de werkelijkheid complexer en genuanceerder is dan simpele karikaturen ervan.

Het is gewoon NIET mijn ervaring dat het een probleem is. Maar misschien komt dat omdat als ik iets schrijf ik
op de achtergrond meteen al bedenk wat er afhankelijk is van bijvoorbeeld woordbreedte en endianness, ik gebruik
gewoon de daarvoor bedoelde functionaliteit (macro's, functies) bijvoorbeeld als ik networking code schrijf, in plaats van
zonder inzicht alles maar neer te pennen en te debuggen "tot het kennelijk werkt".
Als dat de standaard in de software wereld is dan zullen er wellicht mensen een probleem hebben, maar goed dat is
dan hun eigen schuld. En ik denk dat veel van die bedrijven al op de koffie gekomen zijn toen ze hun 32-bit spullen
op 64-bit wilden compileren, dus als we geluk hebben dan hebben ze toen wat geleerd en gaat het nu in een keer goed.
Daarom had ik ook geschreven dat het alleen een probleem is met HEEL SLECHTE software, maar dat mocht
kennelijk niet.

En nogmaals, ik heb zat Linux system draaien op ARM, MIPS, TILE etc en die doen het gewoon. Je moet eens kijken
hoe probleemloos al die pakketten van het PC/Intel platform draaien op ARM systemen zoals de Raspberry Pi.
Dat Microsoft dat niet kan komt omdat Microsoft geen softwarebedrijf is maar een geld verdien machine. Er zijn wel
meer dingen die die lui niet kunnen, maar dat wil niet zeggen dat ze een software probleem zijn. Als de top daar denkt
dat er aan het oplossen van een bepaald probleem geen geld te verdienen is, dan gebeurt het gewoon niet. Dus
als ze geen markt voor Windows op de ARM zien, dan komt dat er niet.

En, dat zou nu best eens kunnen veranderen!!!

Ik vraag me af wat ik overgesimplificeerd heb als je mijn (23:09,13:47) punten - je moest testen, en ook in een hogere taal kunnen platform verschillen nog zichtbaar - zoals de verschillen die ik in 13:47 noemde - maar weer opnieuw benoemt .

Ik heb niet beweerd - en niet bedoeld - dat alle hogere code onbruikbaar is - maar wel dat het vinden en fixen van pijnpunten (of valideren dat je die niet hebt) tijd/moeite kost - en genoeg moeite is om een klein platform te droppen/niet te supporten.
De hobbyisten droom is dat 'target=Alpha; Make all' alles is dat nodig is. Dat het zo niet werkt zei ik, en herhaal jij.

Idealiter _zitten_ de verschillen geisoleerd/geabstraheerd achter een library, de kernel, en de API - voor een groot deel is dat zo.Niet overal & niet altijd - en dat is waarom kleine platformen abandoned worden.

Je moet het stopzetten van ondersteuning van architecturen in de Linux kernel niet verwarren met problemen bij
het compileren van code voor een bepaalde processor. Er komt meer kijken bij een architectuur ondersteunen in
Linux dan alleen het compileren van de 99% van de kernel die niet van de architectuur afhankelijk is. Er zitten
in de kernel ook routines die in feite device drivers voor de chip(set) zijn, zoals de behandeling van de MMU.

Dat heeft echter niks te maken met het compileren van pak em beet een tekstverwerker voor een andere architectuur.
Dat is, tenzij er broddelwerk geleverd is, inderdaad een simpele zaak.
En zelfs lowlevel code die eisen stelt aan woordbreedte en endianness zul je met gebruik van de juiste ondersteuning
(zoals types.h en inet.h) echt geen probleem.

Maar we gaan het zien! Als er binnenkort een winstwaarschuwing van Adobe komt omdat ze een paar honderd
programmeurs onverwacht aan het werk hebben moeten zetten op hun Apple producten dan had je toch gelijk.

Fantastisch wat ze vroeger al konden! :)