Utilisation du sh3eb-elf-gcc sur le SDK
Posté le 24/11/2018 19:09
Pour :
- ne plus être limité par ce 'tain de C89
- utiliser gint
il faudrait modder le SDK pour qu'il utilise le sh3eb-elf-gcc au lieu du compilo Hitachi.
Compiler avec le sh3eb-elf-gcc pour utiliser ensuite sur le SDK, c'est totalement possible (et c'est d'ailleurs ce que je fais avec CasioPython), mais le truc à faire c'est de le faire automatiquement (que quand je fasse "rebuild all" il compile avec gcc).
La cible serait d'après ce que j'ai compris le FXSH_Build.bat qui se trouve dans le dossier du projet, mais pas moyen de l'éditer : il est regénéré à chaque rebuild, et j'ai pas trouvé le template qu'il utilise (doit être compressé dans un .exe quelque part...)
@echo off
rem Do not edit! This batch file is created by CASIO fx-9860G SDK.
if exist debug\*.obj del debug\*.obj
if exist BOFTEST.G1A del BOFTEST.G1A
cd debug
if exist FXADDINror.bin del FXADDINror.bin
"C:\Users\Zezombye\Downloads\fx9860G_SDK_mod\fx-9860G SDK_mod\OS\SH\Bin\Hmake.exe" Addin.mak
cd ..
if not exist debug\FXADDINror.bin goto error
"C:\Users\Zezombye\Downloads\fx9860G_SDK_mod\fx-9860G SDK_mod\Tools\MakeAddinHeader363.exe" "C:\Users\Zezombye\Documents\CASIO\fx-9860G SDK\BOFtest"
if not exist BOFTEST.G1A goto error
echo Build has completed.
goto end
:error
echo Build was not successful.
:end
Une alternative serait de modifier le HMake.exe ou MakeAddinHeader363.exe pour qu'il agisse en tant que wrapper du sh3eb-elf-gcc.
Une idée ?
Citer : Posté le 24/11/2018 19:15 | #
MakeAddinHeader363.exe c'est le g1a-wrapper, je pense, donc rien à voir. HMake.exe c'est le programme qui exécute le Makefile, donc ce n'est pas lui gui le genère. Ça a l'air... compliqué. Je ne vois pas de méthode sans modifier le fichiers exécutables du SDK.
Citer : Posté le 24/11/2018 19:23 | #
Voici le addin.mak :
# Make file for CASIO fx-9860G SDK Addin
#
############################
# Directory defines
TCDIR = C:\Users\Zezombye\Downloads\fx9860G_SDK_mod\fx-9860G SDK_mod\OS\SH
OSDIR = C:\Users\Zezombye\Downloads\fx9860G_SDK_mod\fx-9860G SDK_mod\OS
APPDIR = C:\Users\Zezombye\Documents\CASIO\fx-9860G SDK\BOFtest
OUTDIR = C:\Users\Zezombye\Documents\CASIO\fx-9860G SDK\BOFtest\Debug
################
# Main Defines
SH_EXEDIR=$(TCDIR)\bin
# Hitachi SH C/C++ Compiler02 phase
SHCC02_EXE=shc.exe
SHCC02_DEP="$(OSDIR)\FX\include\fxlib.h"
# Hitachi SH Assembler03 phase
SHASM03_EXE=asmsh.exe
# Hitachi OptLinker04 phase
SHLINK04_EXE=Optlnk.exe
SHLINK04_DEP="$(OSDIR)\FX\lib\fx9860G_library.lib"
SHLINK04_DEP2="$(OSDIR)\FX\lib\setup.obj"
EPSILON="$(OSDIR)\FX\lib\Standard_Library.lib"
#######################
# Files to build
FILE0=BOFtest
FILESRC0="$(APPDIR)\$(FILE0).c"
FILEOBJ0="$(OUTDIR)\$(FILE0).obj"
RFILE=FXADDINror
USERALLOBJ=$(FILEOBJ0)
#######################
# nmake "all" statement
ALL: SH_ENV \
$(USERALLOBJ) \
$(OUTDIR)\$(RFILE).bin \
####################
# Description blocks
!MESSAGE %3#C$z`&'0?
!MESSAGE
!MESSAGE Executing Hitachi SH C/C++ Compiler/Assembler phase
!MESSAGE
SH_ENV :
set SHC_INC=$(TCDIR)\include
set PATH=$(TCDIR)\bin
set SHC_LIB=$(TCDIR)\bin
set SHC_TMP=$(OUTDIR)
$(FILEOBJ0) : $(FILESRC0) $(SHCC02_DEP)
"$(SH_EXEDIR)\$(SHCC02_EXE)" -subcommand=<<
-cpu=sh3
-include="$(OSDIR)\FX\include","$(APPDIR)"
-objectfile=$(FILEOBJ0)
-show=source
-listfile="$(OUTDIR)\$(FILE0).lst"
-size
-noinline
-chgincpath
-errorpath
$(FILESRC0)
-lang=c
-nologo
-debug
<<
!MESSAGE
!MESSAGE Executing Hitachi OptLinker04 phase
!MESSAGE
"$(OUTDIR)\$(RFILE).bin" : $(USERALLOBJ) $(SHLINK04_DEP2) $(SHLINK04_DEP)
"$(SH_EXEDIR)\$(SHLINK04_EXE)" -subcommand=<<
noprelink
sdebug
rom D=R
nomessage
list "$(OUTDIR)\$(RFILE).map"
show symbol
nooptimize
start P_TOP,P,C,D,C$VTBL,C$INIT/0300200,B_BR_Size,B,R/08100000
fsymbol P
nologo
input $(USERALLOBJ)
input $(SHLINK04_DEP2)
library $(SHLINK04_DEP)
library $(EPSILON)
output "$(OUTDIR)\$(RFILE).abs"
-nomessage=1100
end
input "$(OUTDIR)\$(RFILE).abs"
form binary
output "$(OUTDIR)\$(RFILE).bin"
exit
<<
Du coup le compilo en lui-même c'est shc.exe, mais pareil le addin.mak est autogénéré donc pas moyen de le modifier.
Donc oui je pense que la méthode la plus simple est de modifier le makeaddinheader363.exe pour qu'il appelle les programmes qu'il faut
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/11/2018 19:46 | #
Je crois que tu n'as pas compris ce que je voulais dire : MakeAddinHeader363.exe est appelé à la toute fin de la compilation, quand il est utilisé c'est déjà trop tard.
Citer : Posté le 24/11/2018 20:27 | #
Nope, au contraire s'il faut modifier un exe il faut modifier le dernier dans la chaîne (pour virer ce que font les autres .exe).
Du coup lors de l'exécution du FXSH_build.bat, le HMake et le shc.exe génèrent des fichiers, mais le makeaddinheader363.exe modifié génère le fichier final .g1a qui sera exécuté par l'émulateur.
(je testerai ça quand j'en aurai l'occasion, mais j'ai aucune idée de comment programmer un tel .exe en C, et je vais quand même pas le faire en java
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/11/2018 21:20 | #
Nope, au contraire s'il faut modifier un exe il faut modifier le dernier dans la chaîne (pour virer ce que font les autres .exe).
Oui, mais... le fichier binaire qui existe a déjà été compilé. Tu vas me dire que tu comptes laisser le SDK compiler, puis ensuite recompiler avec gcc depuis le wrapper ? Je veux bien, mais c'est super moche... enfin, c'est pas sûr qu'on ait mieux...
Citer : Posté le 24/11/2018 21:21 | #
Ouaip, exact.
Après rien n'empêche de remplacer le reste des .exe par des exe "dummy" comme ça le SDK compile pas 2 fois le code
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/11/2018 21:23 | #
Du coup pour ton exe ce que tu peux faire c'est un programme C qui appelle juste system("ma_compilation") avec ma_compilation un autre programme, potentiellement un script batch pour lancer le compilateur (Cygwin requis je suppose).
Citer : Posté le 24/11/2018 21:30 | #
Ah on peut directement appeler un script depuis un programme C ? (ça parait évident, mais c'est vrai que j'y avais pas pensé
Je vais essayer de faire sans Cygwin justement, normalement l'exe du sh3eb-elf-gcc est lançable directement depuis le batch windows.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/11/2018 21:39 | #
Ah on peut directement appeler un script depuis un programme C ? (ça parait évident, mais c'est vrai que j'y avais pas pensé
Dans le doute, je te l'explique
En gros pour exécuter un script tu n'exécute pas directement ton fichier, tu exécute l'interpréteur correspondant (Python, Batch, Bash, Cling... ) avec en argument le chemin vers ton script. Et il se charge alors d'exécuter une à une tes lignes de code.
Mais comme ces interpréteurs sont des .exe tout ce qu'il y a de plus classique, ça n'a rien d'étranges de les appeler
Citer : Posté le 24/11/2018 21:40 | #
Essaie ceci alors :
#include <stdlib.h>
int main(void)
{
system("truc.bat");
return 0;
}
Avec des commandes pour le batch dans truc.bat dans le même dossier.
Citer : Posté le 05/12/2018 18:54 | #
Après quelques essais (je devais compiler avec mingw au lieu de compiler avec le gcc de cygwin) ça marche, et j'arrive à exécuter un script à partir du "rebuild all" du sdk
Du coup le sdk modifié devrait être dispo bientôt (faudra le remplacer dans la catégorie logiciel).
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 05/12/2018 22:23 | #
Oh, bien joué ! Tu as fait comment du coup ? Les détails techniques m'intéressent !
Citer : Posté le 05/12/2018 22:38 | #
J'ai juste compilé ton code avec mingw puis j'ai mis l'exe à la place du hmake.exe (le makeaddinheader363.exe marche pas parce qu'il y a un check avant).
Par contre vu que le sdk passe pas le chemin d'installation à l'exe, je devrai me débrouiller avec des chemins absolus, et il faudra mettre le sdk dans C:\Casio (l'alternative est de mettre tous les binaires nécessaires dans chaque projet, ce qui est encore moins propre).
Du coup c'est possible et me faut juste un peu de temps pour faire ça
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 05/12/2018 22:40 | #
Tu es sûr que C:\Program Files\CASIO ne serait pas mieux ? C'est le chemin d'installation par défaut.
Citer : Posté le 05/12/2018 22:45 | #
Nan, le chemin par défaut est program files (x86), pour ça d'ailleurs qu'on a souvent des problèmes de parenthèses
Ajouté le 06/12/2018 à 14:32 :
Hmm, ça m'a pas l'air d'être aussi facile que prévu.
Le sh3eb-elf-gcc que j'ai compilé avec cygwin me donne cette erreur lors de la compilation d'un fichier .c :
Je pense que ça vient du truc /cygdrive/c/Users/Zezombye/AppData/Local/Temp/ccbNRLLh.s mais j'ai recréé l'arborescence et j'ai toujours la même erreur :/
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 06/12/2018 16:40 | #
Mais euh, tu lui as passé plein de chemins à la Unix là, tu le lances bien dans Cygwin ton compilateur ? Si tu veux compiler depuis un enrivonnement Windows, je crois que ton seul choix c'est MinGW...
Citer : Posté le 06/12/2018 16:59 | #
Justement non, je le lance depuis le cmd windows (mais vu que je l'ai compilé sous cygwin, j'imagine que c'est pour ça que ça marche pas).
Du coup je devrais recompiler le sh3eb-elf-gcc avec mingw ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 06/12/2018 17:08 | #
Tu veux dire recompiler un « sh3eb-elf-mingw », si tenté que ça existe...