Developpez en assembleur mais quoi ? - Page 2

30

Le 21/07/2014 à 21:56

Nalfus oui, tu peux avoir du 'vrai multitache' sur un ST, dans la gestion des evenements (AES) on a un evnt-timer qui permet d'appeller une routine toutes les x millisecondes.

après effectivement un accessoire est deja en mémoire et le reste, ce qui simplifie une partie du travail.

Pour le Pexec on peux le réecrire car en gros on a quoi comme probleme :

- la gestion de la ram
- la relocation du programme

Car en lancement d'un programme, le TOS reserve toute la ram dispo c'est au prog de rendre la ram non utilisé (Mshrinkl).

En gros réecrire un Pexec ne presente pas a premiere vue de probleme particulier.

J'ai juste un probleme, un lien entre un prog et son 'fils', mais concretement cela est representé comment ?

Si on tu le 'pere' faut aussi 'tuer' le fils je suppose ? Mais il y a que cela ?

Nalfus, merci pour les infos et les liens.

Pour infos un bug a GT en superviseur ou utilisateur ca change rien, ca crash quand même !!

Ca serait donc surtout le 'switch', car killer une tache, en gros, on la retire de notre liste des 'process' et on restitue la ram.

Donc est ce que cela pourrait se 'resumer' comme cela :

avoir un Pexec 'AES', qui permet de charger une application et renverrai un ID.

ensuite lancer ou 'switcher' a cette application avec une autre 'fonction AES'.

Vous m'excuserez si je parle a voix 'haute' mais cela me permet de mieux 'voir' et de poser le problême.

OL est ce que tu vois cela autrement ? Si oui pourrait tu donner ta vision plus 'physique' de la chose ?

GT

Accrochez vous ca va être Cerebral !!

31

Le 21/07/2014 à 23:02

GT Turbo (./30) :
Nalfus oui, tu peux avoir du 'vrai multitache' sur un ST, dans la gestion des evenements (AES) on a un evnt-timer qui permet d'appeller une routine toutes les x millisecondes.

après effectivement un accessoire est deja en mémoire et le reste, ce qui simplifie une partie du travail.

Pour le Pexec on peux le réecrire car en gros on a quoi comme probleme :

- la gestion de la ram
- la relocation du programme

Car en lancement d'un programme, le TOS reserve toute la ram dispo c'est au prog de rendre la ram non utilisé (Mshrinkl).

En gros réecrire un Pexec ne presente pas a premiere vue de probleme particulier.

J'ai juste un probleme, un lien entre un prog et son 'fils', mais concretement cela est representé comment ?

Si on tu le 'pere' faut aussi 'tuer' le fils je suppose ? Mais il y a que cela ?

Nalfus, merci pour les infos et les liens.

Pour infos un bug a GT en superviseur ou utilisateur ca change rien, ca crash quand même !!

Ca serait donc surtout le 'switch', car killer une tache, en gros, on la retire de notre liste des 'process' et on restitue la ram.

Donc est ce que cela pourrait se 'resumer' comme cela :

avoir un Pexec 'AES', qui permet de charger une application et renverrai un ID.

ensuite lancer ou 'switcher' a cette application avec une autre 'fonction AES'.

Vous m'excuserez si je parle a voix 'haute' mais cela me permet de mieux 'voir' et de poser le problême.

OL est ce que tu vois cela autrement ? Si oui pourrait tu donner ta vision plus 'physique' de la chose ?

GT

Je ne vois pas trop pourquoi il faudrait réécrire le Pexec() effectivement il réserve toute la mémoire mais c'est quasiment aussi tôt remis par le programme (mais ce ne serait pas difficile de réserver juste avant de la mémoire et de la relâcher après enfin pas sur que cela marche avec le TOS je ne sais pas comment il gere ses liste de mémoire et fichier si il fait le lien avec la basepage ou non si non faudra se contenter des accessoires seulement). Il y a même le mode 3 qui fait le boulot sans tout réserver a priori (d'après le bout de code que j'ai pour démarrer un accessoire (tiré de OAESIS il n'y a pas grand chose que je n'ai pas codé moi même mais ça cela dépasse un peu ma compréhension) ensuite on recopie notre code d'initialisation, j'avoue c'est assez obscure).

Je pense que si déjà j'arrivais à avoir les accessoires ce serait un pas ensuite on pourra voir si on peut faire mieux.

Je n'ai pas la prétention de réécriture tout gemdos, mint n'est pas bon sur bien des points (pas capable de pouvoir appeler gemdos d'une IT ou d'un signal alors que Magic c'est sans soucis mais on n'a pas les sources de Magic et Magic c'est quasiment que de l'assembleur!)

Olivier

32

Le 06/08/2014 à 10:48

J'arrive à la bourre, je l'avais pas vu ce topic !

Bref, effectivement, l'interfaçage GFA/68000, why not. Mais ce n'était pas mon but premier.
C'était, dans le désordre :
* Comprendre le fonctionnement de l'assembleur sur le 68000 (quitte à ce que ça me serve sur différentes machines, genre l'Amiga... oui, aussi...)
* Je me dis que si je capte à peu près le 68000, je dois pouvoir me dépatouiller ensuite sur du 68020/030/040/060. Et là encore, faire du développement pour ST/Falcon/CT60 (qui en manque cruellement) et mes Amiga (du 68000 au 68060)
* Des démos, des démos, encore des démos. Ouais, je m'y prends sur le tard, mais j'm'en moque ! J'ai envie de développer des p'tits trucs, des machins et même, soyons fous, des bidules !
* De l'utilitaire... si j'en trouve l'utilité.

Donc du coup, utiliser le fenêtrage, les boîtes de dialogues, etc...

Bon... voilà... tout ça c'est bien loin, mais disons que je voudrai arriver à la même autonomie que ce que je développe pour mon plaisir sur PC (en .net, que ce soit avec VB ou C++ ou C#). Je me mets devant et en quelques jours j'ai mon utilitaire pour faire ce dont j'ai besoin. Et je souhaite le faire en assembleur pour le "fun" parce que ça pourrait toujours être en GFABasic, mais le plaisir de pouvoir l'optimiser en assembleur me fait presque rêver...

Je vous vois venir... Mon programme tout pourri en assembleur fonctionnera moins bien que le programme de base en GFABasic... M'en fiche, ce sera LE MIEN !

Atari 520 STE - 4 Mo - HxC/Floppy - CosmosEx
Atari Falcon 030 - 14 Mo - CF intégrée et disque interne IDE 40 Go - CT60 à 90 MHz 256 Mo - SuperVidel - Svethlana / Sous FreeMint/MyAES
Amiga 500/600+Vampire v2/1200+Blizzard 1260-PPC/2000 - Amstrad CPC - Sharp X68000

33

Le 06/08/2014 à 12:32

huggyone76 (./32) :

Je vous vois venir... Mon programme tout pourri en assembleur fonctionnera moins bien que le programme de base en GFABasic... M'en fiche, ce sera LE MIEN !

Je pense que personne n'osera dire cela, ca serait vraiment petit joueur. On avait du un débat avec Stabylo (Removers) sur la beauté du code, oui ce que les gens verront jamais a par ce qui verront votre source.

Cela est con, mais oui pour la beauté du code.

Mais même après quand on retourne a d'autres langages, on modifie ces techniques de programmation, car on sait ce que doit / va faire le compilateur / interpreteur. On programme plus proprement car en assembleur faut tout faire sois même.

Et le monde de la démo, apprend un paquet de technique, super pratique et réutilisable. Un de nos programmeurs travaillait sur des supercalculateurs, il optimisait le code des autres pour le faire tourner plus vite. Les propriétaires des programmes se demandait comment il arrivait a faire tourner leur propre code de 30 a 50% plus vite juste en déplacant des lignes, ou en supprimant des blocs complets !!

GT

Accrochez vous ca va être Cerebral !!

34

Le 06/08/2014 à 16:50

Ah ouais !

Je vois ! Moi qui était un fana de la programmation système quand je travaillais sous Unix, je vois le genre...

Enfin bref, qu'on ose le dire ou pas, j'm'en moque, je m'amuserai au moins sur ma chaise devant mes trucs tout pourris en assembleur !

Mon fils continuera à me regarder avec l'amour d'un gosse, ma femme moins sûr... (elle est ingénieur info comme moi, mais elle déteste la programmation !!!)...

35

Le 06/08/2014 à 18:28

Au collège une prof me disait toujours mieux vaut etre mauvais dans une classe de bon que d'etre bon dans une classe de mauvais.

Donc même un mauvais programme en asm

Accrochez vous ca va être Cerebral !!

36

Le 06/08/2014 à 19:42

Je suis pas totalement d'accord

— Zeroblog —

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

37

Le 06/08/2014 à 19:48

Zerosquare (./36) :
Je suis pas totalement d'accord

Pour la classe ?

Accrochez vous ca va être Cerebral !!

38

Le 06/08/2014 à 20:18

Non je parlais des logiciels, je préfère un bon logiciel fait avec un mauvais langage que l'inverse

39

Le 06/08/2014 à 20:23

Zerosquare (./38) :
Non je parlais des logiciels, je préfère un bon logiciel fait avec un mauvais langage que l'inverse

Essaie pas de nous induire d'erreurs !!!!

(Je m'en doute Zero

je pense pareil mais chut !!)

Le seul probleme des demomakers / fou furieux de l'assembleur c'est souvent la partie interface qui laisse a désirer, on oublie tout le temps qu'il y a des gens 'normaux' qui l'utilisent derrière.

On se fera un petit tuto detente sur le contact avec l''etre humain'..

Comme dirait Fadest : l'informatique sans utilisateur ca marche mieux (Ou quelque chose comme cela !!)

GT

Zero

Accrochez vous ca va être Cerebral !!

40

Le 25/10/2014 à 21:24

Je suis en train de finalisé le tuto 3 et cela m'a fait penser a deux choses. Qui vont surement nous valoir des insultes de certaines personnes mais on s'en fiche car rien nous fais peur (Si un Amiga stable

)

Est ce que un tuto sur le code généré (En gros sur des programmes qui écrivent (genere) des programmmes) et le code auto modifiant (Programme qui modifie leurs instructions eux même, oui je sais on dirait un truc de science fiction présenté comme cela mais c'est pas si compliqué que cela et ca fait des trucs qui feront de vous des dieux !) vous interressent ?

Juste un exemple, chez nous nous avons une routine de ligne qui trace des lignes (Oui je sais, merci de rien dire...), a chaque point affiché, la routine génère (Oui elle écrit) une instruction qui effacera le point affiché. Donc quand vous voudrez effacer cette ligne, vous aurez qu'une ligne a écrire (L'appel au code généré).

C'est gràce a du code généré que Griff (Codeur du groupe Inner Circle) a renvoyez les amigaistes jouez dans leur bac a sable, car son flexiscroller est plus rapide que la version amiga !!! ( Détails dans le flexiscroller : https://www.youtube.com/watch?v=XwgNVnLOYjM )

GT Auto modifiant !!

Accrochez vous ca va être Cerebral !!

41

Le 25/10/2014 à 23:16

Tu crois pas que tu mets la charrue avant les bœufs ?

Fais d'abord un tuto sur des trucs simples

42

Le 25/10/2014 à 23:19

C'est ma spécialité de rien faire dans l'ordre

C'est juste pour la plannification des tutos, oui oui j'essaie de plannifier, de mettre de l'ordre dans les tutos. C'est sur que ca sera pas avant 'quelques' tutos, c'est juste une question,

GT Plus en mode a 'LaRache' !!

Accrochez vous ca va être Cerebral !!