C'est le Basic des premiers IBM PC.celui là je ne connais pas mais il se rapproche du Basic de mes 1ère machines en 8bit
TO7/70 et MO5
a les goto et do / loop un vrai bonheur ;-)
C'est le Basic des premiers IBM PC.celui là je ne connais pas mais il se rapproche du Basic de mes 1ère machines en 8bit
TO7/70 et MO5
a les goto et do / loop un vrai bonheur ;-)
Oui... mais non selon moi. VB6 prétend faire de l'objet sans réellement en faire. C'est toute la difficulté de ce langage car tout le reste est tellement évident que c'en est enfantin.
ça c'est le vrai basic de base avec N° de ligne et pas compilable ?? je pense
Le VB6 et déja orienté objet
Un jeu de carte que j'avais commencé en turbo Pascal, je l'ai terminé en VB en faisant un copie collé du code turbo pascal où j'ai du corriger quelques erreurs de syntaxe.
ça m'a étonné d'avoir pu installé VB6 (qui date de 98) sous W10
Oui... mais non selon moi. VB6 prétend faire de l'objet sans réellement en faire. C'est toute la difficulté de ce langage car tout le reste est tellement évident que c'en est enfantin.
C'est retors comme notion: on ne construit/détruit pas d'objet au sens premier du terme. C'est en revanche à partir de .NET qu'on a des langages réellement objet côté MS.
EDIT: Et puis je suis allé retourner voir les exemples de code "objet" VB6. Cela singe de l'objet, mais ce sont des handlers de comportement, pas de l'objet natif à mon sens. Mais ça se discute.
Le truc est que nativement on peut "imiter" ce comportement mais sans être aussi puissant et précis qu'un langage totalement conçu pour. Pire: on peut mélanger du tout et n'importe quoi là-dedans, ce qui finit à coups de hacks en effet.j'ai bossé 2 ans en VB6 pour une société de gestion d'actifs parisienne. Tout était en VB6 (début dans années 2000). effectivement on avait une architecture qui s'apparentait à des briques objets mais je ne sais plus par quel subterfuge on faisait cela. Mais ce n'est effectivement pas un langage objet Natif.
Le basic des premiers PC était en ROM, on y accédait en démarrant la machine sans support de boot et ce n'était bien sûr pas compilable. Mais si on lançait PC-DOS ou MS-DOS, on avait accès à un Basic plus complet qui était bien évidemment compilable.
ça c'est le vrai basic de base avec N° de ligne et pas compilable ?? je pense
Je caricature évidemment... la compilation est entre les deuxLe basic des premiers PC était en ROM, on y accédait en démarrant la machine sans support de boot et ce n'était bien sûr pas compilable. Mais si on lançait PC-DOS ou MS-DOS, on avait accès à un Basic plus complet qui était bien évidemment compilable.
Pour @magellan : langage machine et assembleur, c'est différent. L'assembleur admet par exemple l'adressage symbolique des données ou des instructions ce qui facilite plus que largement la programmation et encore plus la maintenance.
Dans les "séquentiels", on peut mettre à part les langages type Pascal qui bannissent le Goto.
Et on peut ajouter à ta catégorisation ce qu'on pourrait dénommer les "spaghetti" comme ASP ou PhP...
Tout à fait d'accord ! Cela dit, le premier assembleur, il a bien fallu l'écrire en langage machine... Il y avait aussi la vieille étape du link après compilation qui consistait à intégrer les bibliothèques externes (aujourd'hui on dirait dll).Je caricature évidemment... la compilation est entre les deux
Plus ou moins. C'est un poil plus vicieux (et tu le sais je ne t'apprends rien à ce que je lis). On peut caricaturer en .dll en effet... mais pour ceux qui ne savent pas (et ils sont sûrement de plus en plus nombreux)Tout à fait d'accord ! Cela dit, le premier assembleur, il a bien fallu l'écrire en langage machine... Il y avait aussi la vieille étape du link après compilation qui consistait à intégrer les bibliothèques externes (aujourd'hui on dirait dll).
La notion de segments: quand on n'avait que 640Ko de mémoire basse, on devait jongler avec des segments mémoire.
MOVEM.L D2/D3/D4/A2,-(SP)
LSR.W #1,D1 ; half the buffer
LEA (A0,D1.W),A2 ; points to even bits
LSR.W #2,D1 ; # of longwords (for half)
SUBQ.W #1,D1 ; DBRA entered at top
MOVE.L #$55555555,D4 ; mask for clock bits
MOVEQ #0,D0 ; initial checksum
ch = **string;
if (ch >= 0xD800 && ch <= 0xDBFF) {
ch2 = *string[1];
if (ch2 >= 0xDC00 && ch2 <= 0xDFFF) {
ch = ((ch - 0xD800) << 10) + (ch2 - 0xDC00) + 0x0010000UL;
++read;
}
}
Pour moi l'assembleur et les limitations mémoire, c'est quand j'ai commencé dans l'industrie et qu'on programmait des 68000 pour le pilotage hard de machines (automates, machines outils...)Ahhh le code...
Pour moi le code c'est ça :
ou ça :Code:MOVEM.L D2/D3/D4/A2,-(SP) LSR.W #1,D1 ; half the buffer LEA (A0,D1.W),A2 ; points to even bits LSR.W #2,D1 ; # of longwords (for half) SUBQ.W #1,D1 ; DBRA entered at top MOVE.L #$55555555,D4 ; mask for clock bits MOVEQ #0,D0 ; initial checksum
C:ch = **string; if (ch >= 0xD800 && ch <= 0xDBFF) { ch2 = *string[1]; if (ch2 >= 0xDC00 && ch2 <= 0xDFFF) { ch = ((ch - 0xD800) << 10) + (ch2 - 0xDC00) + 0x0010000UL; ++read; } }
J'y vois un poème naissant, sans blague.
Tout le reste m'ennuie beaucoup. J'ai programmé avec de très nombreux langages, parfois exotiques (BCPL, E), mais jamais avec la passion de l'assembleur et du C. Ce sont les seules façons naturelles de programmer pour moi. Avec le typage, un ramasse-miettes, sans pointeurs et son arithmétique fabuleuse, je suis perdu, tout me semble compliqué.
J'ai débuté avec le langage machine (pas l'assembleur), j'ai ensuite été contrait de faire du Basic sur beaucoup de machines entre le début et le milieu des années 80, mais c'est l'assembleur que j'ai le plus longtemps pratiqué (Z80, 68k puis x86), puis ensuite le C. Lorsque j'ai découvert le PC, c'était un cauchemar avec son modèle mémoire segmenté par rapport au modèle FLAT du 68k. Par contre lorsque j'ai dû programmer le firmware d'un petit appareil avec une puce ARM il y a 4 ans (à titre de hobby, en open source), j'ai mis très peu de temps à me familiariser avec le jeu d'instructions que je ne connaissais pas du tout.
Je ne comprends pas grand chose à des langages comme les C# ou le Java (et je n'ai pas envie de faire d'effort pour ça). Il faut potasser des encyclopédies ennuyeuses de fonctions, comme lorsque j'avais dû apprendre l'intégralité des ROM Kernel de l'Amiga, des API Win32 et du framework WDM. C'est pas drôle. Sur l'Amiga c'était facile, on prenait le contrôle total du hardware au boot et on faisait ce qu'on voulait sans se soucier de la ROM (en gros équivalente au BIOS). Piloter le matériel était possible en partant de rien et sans aucune librairie. J'avais par exemple, pour une démo, fait jouer de la musique au lecteur de disquette en pilotant le moteur pas à pas. Cela avait eu son effet C'est pas la même aujourd'hui, on démarre sur un OS et lui nous dit : "ah non, t'as pas le droit d'accéder directement à ce périphérique pour allumer sa led mon coco, je supervise tout, va falloir te farcir les modèles WDM et KMDF.". C'est pas rigolo.
Même si je ne travaille plus du tout dans ce domaine depuis longtemps, la programmation m'a passionnément dévoré depuis jeune, il y a 40 ans, et je continue de temps à autre à programmer. Cela a du sens dans mon parcours plus artistique que technique. Faire des films, concevoir ou programmer une machine et composer de la musique, c'est pour moi la même chose : on crée quelque chose à partir de rien, on concrétise une idée. L'aspect créatif des programmeurs n'est pas assez mis en avant il me semble. C'est magique de partir d'une feuille blanche puis de faire naitre peu à peu un programme, un jeu, quelque chose avec lequel d'autres vont pouvoir interagir, travailler, s'amuser et même éprouver des émotions.
Je développe mes sites web, et ça, ça m'ennuie prodigieusement, ça ne n'amuse pas du tout. Je trouve ça plus compliqué, moins drôle et moins gratifiant que de développer un firmware en assembleur ou C. Ce n'est qu'un site web parmi tant d'autres interprété dans le navigateur d'un OS, alors qu'un firmware, c'est ce programme entièrement autonome qui donne "vie" à l'appareil et permet de l'utiliser. Mais heureusement que tout le monde ne pense pas comme moi
tout s'apprend j'"en suis la preuve.Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25. Franchement ca a beau avoir que 20 Ko de mémoire mais ca suffit large lol la plupart de mes programmes font quelques dizaines d'octets. Le seul problème c'est que je galère car programmer une calculette c'est long et j'ai casiment jamais fait de la programmation ne serait ce sur ordinateur
Pas grand chose, j'ai pris ça au hasard, c'est le tout début (l'initialisation) d'une routine du pilote assurant la gestion du codage MFM des disques du Kickstart d'AmigaOS (une sorte de BIOS).7 lignes de code qui font quoi ?
Je l'ai fait à une époque ! On me l'avait demandé parce qu'on aimait mon approche plus artistique que technique. Je passais pour un déluré avec mes longs cheveux rouges et mon tempérament passionnéTu donnes des cours ? ...Non t'es un peu loin ..MDR...
Beaucoup étaient développés en C. Mais à cette époque, on pouvait parfaitement développer un jeu seul 100% en assembleur (et donc adieu la portabilité). Ce n'est pas le cas aujourd'hui, bien qu'une petite bande de malades développe depuis des années un OS 100% en assembleur (MenuetOS). Je trouve ça fascinant de voir leur avancée.Clair que tous les jeux du commodore 64 étaient surement développé en assembleur
D'une c'est du C++, de deux je ne connais pas assez les échecs pour me plonger dans ce genre de code et de trois des gens bien plus qualifiés que moi (en C++ et en échecs) doivent pulluler y compris sur ce forumSi j'ai bien compris tu pourrais entrer dans le code source qui est Open source, de StockFish ..
C'est génial pour apprendre et pour s'amuser ! Pas besoin d'une machine de malade avec 1To de RAM.Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25.
Putain qu'est-ce que j'ai aimé cette architecture... Elle avait ses défauts mais tellement de qualités face aux x86 puants de l'époque.Pour moi l'assembleur et les limitations mémoire, c'est quand j'ai commencé dans l'industrie et qu'on programmait des 68000 pour le pilotage hard de machines (automates, machines outils...)
J'ai commencé la logique de programmation et celle du calcul avec itération avec la Texas instrument TI 57Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25. Franchement ca a beau avoir que 20 Ko de mémoire mais ca suffit large lol la plupart de mes programmes font quelques dizaines d'octets
Si si je me souviens très bien. J'ai eu un Atari ST, et il y avait un port dédié cartouche. Je n'avais pas les moyens de m'offrir ce machin, mais ST Mag en parlait régulièrement. Il y a eu au aussi la cartouche pour faire tourner une "émulation" (le terme n'est pas vraiment le bon mais c'est le seul qui colle un peu) pour faire de son Atari un Mac!J'ai commencé la logique de programmation et celle du calcul avec itération avec la Texas instrument TI 57
Il fallait bien 24h pour qu'elle calcule PI avec 7 décimale (peut être moins je me souviens plus)
Puis quand tu avais programmé un truc avec une fois éteinte ..Bin il resté que dalle fallait tout recommencer
7 mémoires si je me souviens et le nombre de pas de programme était assez limité aussi.
C'était en 82 je crois !!! TI la ventait comme un objet de sience fiction à l'époque. Puis sont sortis en masse les Oric Commodore TO7 ..Etc...Et puis les ATARI avec leur 6800 Motorola 8 Mhz et 32 bits en interne
Et le lecteur de disquette du commodore 64 qui valait l'équivalent à l'aise de 500 600€ de maintenant ..80 KO si j'ai bon souvenir par disquette
Et si on le boostait pas chargé 30 KO mettait presque 5 mn (au moins 2 mmn en tout cas)
Mais c'est un temps que les moins de .... ne peuvent pas connaître ...MDR...
Avant d'avoir un PC Je m'étais fait acheter par le collége un boitier qui transformait L'Atari en PC 8086 ..
Personne n'a connu ça ici ? il avait son processeur un Nec V30 (meilleur que le 8086 de Intel) ..comment je branchais ça sur l'Atari je me souviens plus