Librairies pour le NoStub - Page 1

Je cherche des librairies pour assembleur sous A68k, et en NoStub !!!
Par exemple, comment se débrouiller pour faire du Gray 4, mais sans le programmer soi-même ?

Et où en sont les libs dynamiques en NoStub (comment on arrive à s'en servir, déjà, et comment les DLLs de TIGCC marchent)

1. Ne parle pas de Libs dynamiques en _nostub. C'est une aberation.
2. Tu fais un appel a GrayOn:
bsr GrayOn.
3. Tu peux utiliser toutes les fonctions incluses dans tigcclib.a par de simples bsr (ou jsr) sans inclusion de header.
4. Lis la doc de tigcc.
5. Ne parle plus des DLL _nostub.
6. Je repete: c'est un non-sens de faire une DLL _nostub.

Et voilà, pour une fois, je suis entièrement d'accord avec PpHd. Mais pas pour la même raison.

Et voilà, pour une fois, je suis entièrement d'accord avec PpHd

c'est émouvant :')

Pen²: oué mais pas la suite :/

oui, c'est pour ça que je ne l'ai pas mis dans le cite

DLL powa sutout ne pas esiter a en abusé pour le fun !

JackosKing
: DLL powa sutout ne pas esiter a en abusé pour le fun !

Bon, je pige rien là.

On m'avait dit que le FAT Engine s'arrangeait à ce niveau là pour des libs dynamiques.

Enfin, les DLLs de TIGCC sont utilisées en assembleur GNU, on doit bien pouvoir s'en servir avec A68K ?!?!?

Autre question: on peut exploiter le nouveau linker de TIGCC 0.95 et faire des BSS en NoStub sous A68k ?

EvilAngel :
Bon, je pige rien là.
On m'avait dit que le FAT Engine s'arrangeait à ce niveau là pour des libs dynamiques.

Oui, mais FAT Engine est un cas particulier. Il s'agit d'une librairie de plus de 32 KO. Et les programmes clients eux-mêmes sont aussi souvent très gros, donc on dépasse facilement les 64 KO en tout. Donc il faut couper en 2. Ceci est le seul intérêt des DLLs _nostub: pouvoir couper en 2 un programme qui dépasse les 64 KO. Tout le reste est un abus du système. Pour du partage de code, il y a le système de librairies statiques qui est prévu pour.

Enfin, les DLLs de TIGCC sont utilisées en assembleur GNU, on doit bien pouvoir s'en servir avec A68K ?!?!?

Oui, mais vu tes intentions, je ne te dirai certainement pas comment faire.

EvilAngel
: Autre question: on peut exploiter le nouveau linker de TIGCC 0.95 et faire des BSS en NoStub sous A68k ?

Oui.

_tigcc_native: xdef _tigcc_native

__ref_all___startup_code: xdef __ref_all___startup_code

__ref_all___kernel_format_bss: xdef __ref_all___kernel_format_bss
;Tu peux aussi utiliser "compressed_format" au lieu de "kernel_format".

__ld_omit_bss_init: xdef __ld_omit_bss_init
;sauf si tu veux que tes sections BSS soient automatiquement initialisées à 0.

 xdef __main

__main:
;Commence ton programme ici.

Au cas où tu te retrouves avec un saut vers __main juste au-dessus du label, l'optimisation du linker va le virer. Et en plus, les BSS nécessitent du nettoyage à la fin, donc __main est appelé par un bsr, pas par un simple saut, donc il n'y a pas de saut inutile.

Pour du partage de code, il y a le système de librairies statiques qui est prévu pour.
>> c'est plus du partage...

Si. On écrit le code une fois et plusieurs programmes peuvent l'utiliser, donc c'est du partage de code.

pas sur la calculatrice. le code est en plusieur exemplaire donc pas partagé
tout depend de quoi on parle

Greuuux. Je me demande si je vais pouvoir compiler Preos avec le nouveau linker .

S'il vous plait, vous n'allez pas recommencer à vous disputer dans ce débat stérile.
Ca finit toujours en pugilat, alors il vaut mieux ne pas parler ici de partage de code...

La réponse à la question a été donnée...

PpHd
: Greuuux. Je me demande si je vais pouvoir compiler Preos avec le nouveau linker .

Tu peux:

E:\TI-89\ticunoff\asm\shells\preos\Src>tigcc -v preos.asm -WA,-vhw2tsr -WA,-vShi
ftOn=2 hw2tsr\h220xtsr.a
E:\TI-89\COMPIL~1\TIGCC\BIN\A68K.EXE -iE:\TI-89\COMPIL~1\TIGCC\INCLUDE\ASM\ -g -
t -vhw2tsr -vShiftOn=2 preos.asm
68000 Assembler - version 2.71.F3o (Oct 5, 2003)
Copyright 1985 by Brian R. Anderson
AmigaDOS conversion copyright 1991 by Charlie Gibbs.
Adapted for use with Fargo by David Ellsworth.
Win32 port copyright 2001-2003 by Kevin Kofler for the TIGCC project
Bugfixes and additions by Julien Muchembled, Paul Froissart and Kevin Kofler

Assembling preos.asm

PASS 1 line 4056
PASS 2 line 4056
End of assembly - no errors were found.
Heap usage:  -w4095,196
Total hunk sizes:  1590 code, 0 data, 0 BSS


Program Variable Size:                      6777 Bytes
Absolute Relocs:                            2
Natively Emitted Relocs:                    2

(Il y a quelques octets de plus parce que j'ai rajouté la nouvelle signature des hooks d'évènements dans ces sources.)

C'est bon alors

D'ailleurs, tu peux maintenant mettre:
-o preos-tictex -n preos
pour ne pas avoir à renommer la version -tictex à la main. (-o change le nom on-PC, -n le nom on-calc. Si -n n'est pas spécifié, le nom on-calc est calculé à partir du nom donné en -o comme avant.)

Tu sais j'ai des trucs pour automatiser cela

J'ai vu le fichier .bat, mais c'est quand-même du bidouillage qui n'est plus nécessaire.

Je le garde quand meme

Ca me gave, ces coups de pas de lib dynamique en NoStub.
Il faudrait faire des exécutables NoStub,
qui commencent par un header avec un rts pour pas d'exécution, le nom de la lib,
un octet de version, les offsets 16bits vers chacune des fonctions, et puis les fonctions....

Et implémenter un truc dans le header des progs NoStub, genre une macro pour appeler
une fonction donnée d'une lib donnée dans telle version au moins (ou p-ê des symboles ? Je sais pas m'en servir, à quoi ca correspond une fois compilé)

Edit: l'intérêt est d'avoir du code partagé.

Kevin Kofler > Tu vas me dire "le système de code partagé des libs statiques"

Ben voui mais si tu veux t'as qu'à faire un prog avec un rts, puis les appels à toutes
les fonctions de la lib statique. Ca te fait un ASM permettant d'utiliser les
fonctions de la lib (grace au code partagé) et servant qu'à ça.

Donc... une lib dynamique.

Au fait, je suis pas en train d'en venir au concept du Kernel 1, moi ???
Une macro d'appel dans chaque prog pour accéder au libs... Fait penser à du Kernel 1...

Donc tu passes au mode kernel

Sans penser à ça. C'est possible ce que j'ai dit là-haut ?

PpHd :
Donc tu passes au mode kernel

c clair ça me fait marrer tout ça, il y a de plus en plus de posts dans ce genre :

bonjour je veux connaitre la valeur de tel ou tel ram_call sans me faire ch**, avoir un anticrash, des bibliothèques dynamiques, des pack-archives, etc, mais surtout je veux que ça soit en nostub, parce que le kernel, c pas bien...

Regardes l'auteur, bougre d'imbécile.

!slap Pen^2
• EvilAngel slaps Pen^2 around a bit with a large trout !




Alors PpHd ?