TIGCC 0.95 Beta 8 - Page 2

>Et au passage, l'utilisation de words pour des références entre sections est à qualifier de bogue à mon avis.
Mais je n'ai jamais eu qu'une seule section, moi.

Deplace les tables, dans la section 2, et evite l'adressage via pc.

Bon, là ça compile (toujours en monolithique, mais avec ld-tigcc et les 2 sections), mais ça fait 160 octets de plus parce que j'ai été obligé de déplacer des trucs de la section de démarrage à la section principale.

PpHd :
>Et au passage, l'utilisation de words pour des références entre sections est à qualifier de bogue à mon avis. Mais je n'ai jamais eu qu'une seule section, moi.

Partir du principe que des trucs dans BASE1 et des trucs dans BASE2 sont à une distance de moins de 32 KO me semble assez risqué.

Pour l'optimisation du linker, impossible de l'essayer (du moins pas avec l'option avec laquelle ça sert: le range-cutting), PedroM utilise plein de constructions saugrenues qui sont incompatibles avec le mode all-relocs.

Flash.asm line 171
pedrom.asm line 45
 2254           move.w  #((\FlashWrite_ExecuteInRam_End-\FlashWrite_ExecuteInRam)/2-1),d0
                           ^ Relocatability error.

Flash.asm line 273
pedrom.asm line 45
 2356           move.w  #((\FlashErase_ExecuteInRam_End-\FlashErase_ExecuteInRam)/2-1),d0
                           ^ Relocatability error.

Flash.asm line 1001
pedrom.asm line 45
 3124           move.w  #(TIBReceivEnd-TIBReceiv)/4,d0
                          ^ Relocatability error.

library.asm line 27
pedrom.asm line 64
13049           dc.w    (PedoMLibExportTableEnd-PedoMLibExportTable-2)/2
                         ^ Relocatability error.

shell2.asm line 408
pedrom.asm line 76
25523                   addq.l  #WriteModeStr-ReadModeStr,a1    ; default: 32767
36436write
                                ^ Operand size error.
                                ^ Relocatability error.

shell2.asm line 415
pedrom.asm line 76
25530                           addq.l  #AppendModeStr-WriteModeStr,a1  ; mode: append
                                        ^ Operand size error.
                                        ^ Relocatability error.

Vectors.asm line 284
pedrom.asm line 86
32129           move.w  #(__offRAMEnd-__offRAM)/2-1,d1
                          ^ Relocatability error.

RomCalls.h line 17
pedrom.asm line 105
35379    dc.l (ROMCALLS_TABLE_END-ROMCALLS_TABLE)/4
               ^ Relocatability error.

End of assembly - 10 errors were found.

Et c'est dommage, le range-cutting économiserait 16 octets:

Relocs Saved by Branch Optimization:        31
Relocs Saved by Move Optimization:          10
Relocs Savable by F-Line Jumps:             1178
Space Savable by Range-Cutting:             16 Bytes

16o ! waouh sur combien de ko ?

et puis, je ne suis pas sûr que ça économise vraiment les 16o

PedroM est déjà optimisé à fond et ça se voit. Mais on voit quand-même que notre linker est plus puissant que n'importe quel programmeur, même PpHd.

Flanker
: et puis, je ne suis pas sûr que ça économise vraiment les 16o

À cause des secteurs de taille fixe, ça n'a pas vraiment d'importance pour une ROM en effet.

./37> en même temps, si PpHd avait codé comme un porc, je sais pas si le linker aurait été capable d'optimiser autant que PpHd lui-même...

Évidemment que non, ce n'est pas le but de l'optimisation du linker.
Mais pour ce pour quoi elle est prévu, c'est-à-dire réduire la taille des instructions à ce qui est vraiment nécessaire (et pour les targets autre que le TIB, la suppression des relogements), elle est pratiquement insurpassable.

moué.
ce qui n'est peut-être pas plus mal

> Bon, là ça compile
Cool.

>Partir du principe que des trucs dans BASE1 et des trucs dans BASE2 sont à une distance de moins de 32 KO me semble assez risqué.
Ce n'est pas vraiment risque. Ca ne fait juste que reporter une erreur a la compilation par a68k, c'est tout.
Et ce genre d'erreurs, je l'ai eu souvent.

>Et c'est dommage, le range-cutting économiserait 16 octets:
Seulement 16 octets ?
Les fichiers .c -> .s -> .asm sont largement optimisables par le linkeur question taille, je pense.
Mais je me refuse de patcher a la main.

*VTI ne vérifie aucun checksum et trouve juste à quel endroit est placé l'équivalent du .tib, je pense.*

Je pense aussi. (Mais à la fin d'un .??u, il y a un checksum 16 bits dez tout l'éuquivalent
du tib, ça ça peut se faire par le linker, en revanche une signature cryptée ou un hash
pourrait me bloquer... je ne suis pas sûr qu'on pourra envoyer des OS par TIGL/ TI Connect
un jour.

Kevin > Je me suis heurté exactement aux mêmes erreurs (mais tu les a résolues on dirait)
Si tu peux me mailer la source de ce PedRom utilisable avec ld-tigcc, ça m'arrangerait bien.

Billy Charvet :
Je pense aussi. (Mais à la fin d'un .??u, il y a un checksum 16 bits dez tout l'éuquivalent
du tib, ça ça peut se faire par le linker, en revanche une signature cryptée ou un hash
pourrait me bloquer... je ne suis pas sûr qu'on pourra envoyer des OS par TIGL/ TI Connect un jour.

Les anciennes versions du logiciel TI-GraphLink ne vérifiaient aucun checksum. Pour les nouvelles, je ne sais pas comment elles se comportent.

Kevin > Je me suis heurté exactement aux mêmes erreurs (mais tu les a résolues on dirait) Si tu peux me mailer la source de ce PedRom utilisable avec ld-tigcc, ça m'arrangerait bien.

Voilà mes modifs:

diff -Nur orig/C/BITMAP.ASM ld-tigcc/C/BITMAP.ASM
--- orig/C/BITMAP.ASM	Tue Dec 31 23:31:18 1996
+++ ld-tigcc/C/BITMAP.ASM	Mon May  3 18:49:00 2004
@@ -528,3 +528,34 @@
 	 movem.l -24(a6),#$478
 	unlk a6
 	rts
+
+;void DrawIcon (short x, short y, const void *Icon, short Attr)
+DrawIcon:
+	move.w	4(a7),d0	; x
+	move.w	6(a7),d1	; y
+	move.l	8(a7),a0	; Icon
+	move.w	12(a7),d2	; ATTR
+DrawIcon_reg
+	cmpi.w	#3,d2
+	bne.s	\NoShade
+		; It seems that it should do set or erase a pixel according to a tiny cpt
+		; I don't want to support it. Maybe in the future ?
+		moveq	#1,d2	; ATTR = A_NORMAL
+\NoShade:			; ATTR = A_REVERSE doesn't work directly
+	cmpi.w	#2,d2
+	bhi.s	\Ret
+		move.l	CURRENT_SCREEN,-(a7)
+		move.w	#2,-(a7)
+		pea	(a0)
+		move.w	#16,-(a7)
+		move.w	d1,-(a7)
+		move.w	d0,-(a7)
+		add.w	d2,d2
+		move.w	DrawIconTable(pc,d2.w),d2
+		jsr	DrawIconTable(pc,d2.w)
+		lea	16(a7),a7
+\Ret:	rts
+DrawIconTable:
+	dc.w	SpriteX8_and-DrawIconTable
+	dc.w	SpriteX8_or-DrawIconTable
+	dc.w	SpriteX8_xor-DrawIconTable
diff -Nur orig/Graph.asm ld-tigcc/Graph.asm
--- orig/Graph.asm	Wed Jan  1 00:21:24 1997
+++ ld-tigcc/Graph.asm	Mon May  3 18:48:44 2004
@@ -2110,37 +2110,6 @@
 	movem.l	(a7)+,d3-d5/a2-a3
 	rts
 	
-;void DrawIcon (short x, short y, const void *Icon, short Attr)
-DrawIcon:
-	move.w	4(a7),d0	; x
-	move.w	6(a7),d1	; y
-	move.l	8(a7),a0	; Icon
-	move.w	12(a7),d2	; ATTR
-DrawIcon_reg
-	cmpi.w	#3,d2
-	bne.s	\NoShade
-		; It seems that it should do set or erase a pixel according to a tiny cpt
-		; I don't want to support it. Maybe in the future ?
-		moveq	#1,d2	; ATTR = A_NORMAL
-\NoShade:			; ATTR = A_REVERSE doesn't work directly
-	cmpi.w	#2,d2
-	bhi.s	\Ret
-		move.l	CURRENT_SCREEN,-(a7)
-		move.w	#2,-(a7)
-		pea	(a0)
-		move.w	#16,-(a7)
-		move.w	d1,-(a7)
-		move.w	d0,-(a7)
-		add.w	d2,d2
-		move.w	DrawIconTable(pc,d2.w),d2
-		jsr	DrawIconTable(pc,d2.w)
-		lea	16(a7),a7
-\Ret:	rts
-DrawIconTable:
-	dc.w	SpriteX8_and-DrawIconTable
-	dc.w	SpriteX8_or-DrawIconTable
-	dc.w	SpriteX8_xor-DrawIconTable
-	
 ;void DrawFkey (short x, short y, short fkey_no, short Attr) 
 DrawFkey:
 	clr.w	-(a7)
Binary files orig/MAKE89.PIF and ld-tigcc/MAKE89.PIF differ
diff -Nur orig/Make89.bat ld-tigcc/Make89.bat
--- orig/Make89.bat	Tue Dec 31 23:29:08 1996
+++ ld-tigcc/Make89.bat	Mon May  3 20:55:10 2004
@@ -1,8 +1,5 @@
 @del pedrom89.tib
 @del pedrom89.sav
-@ttstrip ..\Preos\stdlib.9xz stdlib.bin
-@a68k -t -i..\Preos\Src -iC pedrom.asm -lC:\temp\listing.txt -vTI89
+@..\ttstrip Preos\stdlib.9xz stdlib.bin
+@tigcc -v --optimize-code --flash-os --outputbin -WA,-i..\Preos,-iC,-vTI89 pedrom.asm
 @del stdlib.bin
-@maketib pedrom.o
-@del pedrom.o
-@ren pedrom.tib pedrom89.tib
\ No newline at end of file
diff -Nur orig/PedroM.asm ld-tigcc/PedroM.asm
--- orig/PedroM.asm	Tue Dec 31 23:53:18 1996
+++ ld-tigcc/PedroM.asm	Mon May  3 18:42:42 2004
@@ -31,7 +31,7 @@
 ROM_BASE		EQU	$200000	; $400000 for ti92+ / $200000 for 89 & V200	
 	endif	
 **********************************************************
-	RORG	ROM_BASE+$012088
+	section "_st1"
 	include "Vectors.h"		; Vectors's table
 	include	"Mem.h"			; Macros usefull for defining struct
 	include	"Const.h"		; Constants 
@@ -60,7 +60,7 @@
 ***  $418000-$419FFF       8K      [read protected]	***
 ***							***
 ***********************************************************
-	RORG	ROM_BASE+$1A000
+	section ".text"
 	include "library.asm"		; Export API
 	include	"Printf.asm"		; Printf functions
 	include "Kernel.asm"		; Kernel functions
Binary files orig/Preos/STDLIB.89Z and ld-tigcc/Preos/STDLIB.89Z differ
Binary files orig/Preos/Stdlib.9xz and ld-tigcc/Preos/Stdlib.9xz differ
diff -Nur orig/Strings.asm ld-tigcc/Strings.asm
--- orig/Strings.asm	Tue Dec 31 23:13:46 1996
+++ ld-tigcc/Strings.asm	Mon May  3 18:36:18 2004
@@ -145,14 +145,6 @@
 ST_StrC	dc.b	"USE left right + [ENTER]=OK AND [ESC]=CANCEL",0
 ST_StrD	dc.b	"USE [2ND] [KEYS] OR [ESC]=CANCEL",0
 
-BT_NONE_str	dc.b  "None",0
-BT_OK_str	dc.b  "Enter=OK",0 
-BT_SAVE_str	dc.b  "Enter=SAVE",0 
-BT_YES_str	dc.b  "Enter=YES",0
-BT_CANCEL_str	dc.b  "Esc=CANCEL",0 
-BT_NO_str	dc.b  "ESC=NO",0 
-BT_GOTO_str	dc.b  "Enter=GOTO",0
-
 AppsDialogTitle	dc.b	"APPLICATIONS & MODE",0
 AppsText	dc.b	"APPS/MODE menu not implemented.",10,"Wait for next release.",0
 
diff -Nur orig/Window.asm ld-tigcc/Window.asm
--- orig/Window.asm	Wed Jan  1 01:23:08 1997
+++ ld-tigcc/Window.asm	Mon May  3 18:36:22 2004
@@ -1243,6 +1243,14 @@
 	dc.w	BT_NO_str-DrawStaticButtonTable
 	dc.w	BT_GOTO_str-DrawStaticButtonTable
 
+BT_NONE_str	dc.b  "None",0
+BT_OK_str	dc.b  "Enter=OK",0 
+BT_SAVE_str	dc.b  "Enter=SAVE",0 
+BT_YES_str	dc.b  "Enter=YES",0
+BT_CANCEL_str	dc.b  "Esc=CANCEL",0 
+BT_NO_str	dc.b  "ESC=NO",0 
+BT_GOTO_str	dc.b  "Enter=GOTO",0
+
 ;void WinDrawButton(WINDOW *w, short x, short y, char *str, short width, short height);
 WinDrawButton:
 	bsr	_WinSetSystemVar
Binary files orig/pedrom-89.tib and ld-tigcc/pedrom-89.tib differ
Binary files orig/pedrom89.tib and ld-tigcc/pedrom89.tib differ

(Qu'on utilise --optimize-code ou non ne change rien parce qu'il n'y a pas de relogements. --cut-ranges aiderait, mais je dois d'abord virer les "relocatability errors".)

Pas facile de passer en compilation séparée.

(user macro) line 3
Dialog.asm line 1275
pedrom.asm line 50
 7482           dc.w    Ln_XRstr-STRINGS
                                 ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1276
pedrom.asm line 50
 7486           dc.w    Exp_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1277
pedrom.asm line 50
 7490           dc.w    Sin_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1278
pedrom.asm line 50
 7494           dc.w    Cos_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1279
pedrom.asm line 50
 7498           dc.w    Tan_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1280
pedrom.asm line 50
 7502           dc.w    ASin_XRstr-STRINGS
                                   ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1281
pedrom.asm line 50
 7506           dc.w    ACos_XRstr-STRINGS
                                   ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1282
pedrom.asm line 50
 7510           dc.w    ATan_XRstr-STRINGS
                                   ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1283
pedrom.asm line 50
 7514           dc.w    Sqrt_XRstr-STRINGS
                                   ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1284
pedrom.asm line 50
 7518           dc.w    Int_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1285
pedrom.asm line 50
 7522           dc.w    Der_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1286
pedrom.asm line 50
 7526           dc.w    Sigma_XRstr-STRINGS
                                    ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1287
pedrom.asm line 50
 7530           dc.w    Inv_XRstr-STRINGS
                                  ^ Relocatability error.

(user macro) line 3
Dialog.asm line 1288
pedrom.asm line 50
 7534           dc.w    Ans_XRstr-STRINGS
                                  ^ Relocatability error.

Script.asm line 48
pedrom.asm line 59
14396           moveq   #ScriptHeader_end-ScriptHeader_str,d0
                                          ^ Relocatability error.

Les différences d'adresses prises dans l'autre section, ce n'est pas malin. AMS n'est peut-être pas assez optimisé, mais PedroM est trop optimisé pour être maintenable.
Je vais passer la table dans Dialog.asm en assembleur GNU, nous l'avons patché exprès pour gérer ce genre de trucs.

Encore, bis!

Je sais pas , j y comprend rien.Mais il vaut mieux entendre ca que le contraire.

Bon, il y a encore du boulot à faire pour la compilation séparée. L'idée de compiler la table des XR avec GNU as n'était pas si bonne que ça à cause de tous les offsets relatifs qui empêchent de la mettre n'importe où...

Je pense presque qu'il soit plus simple d'améliorer le support pour les relogements négatifs dans A68k que d'essayer d'adapter PedroM aux limitations actuelles. Quoique... J'ai déjà eu du mal à implémenter ce qu'il y a actuellement pour les relogements négatifs. Et pour les relogements négatifs vers un symbole, il faudrait aussi adapter le code d'importation dans le linker.
Si seulement PedroM utilisait l'assembleur GNU... Mais tout changer pour utiliser l'assembleur GNU me fait peur...

Bon, j'ai trouvé une solution (encore 64 octets de plus dans la section principale - j'ai été obligé de déplacer les chaînes XR).

http://yn1.free.fr/up/pedrom-ld-tigcc-3.diff.txt

Pour les xdef, j'ai pris les messages d'erreur du linker et fait un "remplacer tout".

Avec ça, le problème du nombre maximum de lignes devrait être règlé une fois pour toutes.

Pourtant j'aimerais en faire une version as. (Peut être utile, spécifiquement pour
le bootcode, pour en faire une version modifiée capable de booter un noyau selon
des conventions qui restent encore à définir ----> boot Pyrix)

ouééé un fork de Pedrom en ASM GNU

Bah, pas vraiment...juste pour s'en servir pour qqes trucs.

N'oublie pas. PedroM est sous license GPL, y compris le boot code !

Tu as peut etre quelque chose de plus explicite a dire que ce que tu as dit la juste a l'instant ?

DSC, peut-être ?

Pollux > Ah ouais ? Bon. Hé bien disons que je veuille sortir deux trucs totalement à part
et pas liés: Pyrix et un bootloader sous GNU basé sur le bootcode PedRom.

Pyrix aurait un binaire non amorçable, inutilisable tel quel.

Rien ne m'empêche de les distribuer, et en vertu de la loi, un utilisateur
a le droit de faire fonctionner Pyrix avec le bootloader GNU basé sur PedRom.
Je n'ai pas le droit de lier du GNU à un projet propriétaire et de le distribuer, mais l'utilisateur
a beaucoup de droits quand il s'agit d'intéropérabilité, y compris désassembler ou
décompiler les parties d'un binaire propriétaire de façon à ce que ça marche avec un autre
logiciel. Et il a parfaitement le droit de le lier au bootloader GNU, il se trouve que Pyrix passerait
bien avec. (Mais ce n'est qu'une simple suggestion à l'utilisateur...)

Autre idée, vu que je déteste l'idée "libre != gratuit", hé bien je peux le publier sous licence
GNU.............. à 50 €

Et seules les anciennes versions seront gratos. Ca c'est très méchant, mais bon....

Ca me ferait ch*** de le publier sous GNU, donc sinon vu que c'est à la discrétion de
PpHd on pourrait s'accorder à ce que le bootloader soit GNU mais puisse être utilisé
avec le code de l'OS, libre, et sous licence BSD, disons.

Si tu mets ton OS sous licence BSD (la nouvelle sans la "advertising clause"), c'est compatible avec la GPL, donc tu peux utiliser le code de PedroM dans ce cas. Cela dit, personne d'anti-GPL ne pourra profiter de ta licence BSD sans réécrire le code de démarrage sous GPL.