Section courante

A propos

Section administrative du site

 Langage  Elément  Tutoriel  Aide 
ABAP/4
Ada
Assembleur
Assembly & bytecode
ASP (Active Server Pages)
Basic
C
C++
C# (C Sharp)
Cobol
ColdFusion
Fortran
HTML
Java
JavaScript
LISP
Logo
LotusScript
Oberon
Pascal
Perl
PHP
PL/1
Prolog
Python
Rebol
REXX
Ruby
Rust
SAS
NoSQL
SQL
Swift
X++ (Axapta)
GNAT
SMALLAda
VHDL
Assembleur 370
Assembleur 1802
Assembleur 4004
Assembleur 6502
Assembleur 6800
Assembleur 68000
Assembleur 8080 et 8085
Assembleur 8089
Assembleur 80x86
Assembleur AGC4
Assembleur ARM
Assembleur DPS 8000
Assembleur i860
Assembleur Itanium
Assembleur MIPS
Assembleur PDP-11
Assembleur PowerPC
Assembleur RISC-V
Assembleur SPARC
Assembleur SuperH
Assembleur UNIVAC I
Assembleur VAX
Assembleur Z80
Assembleur Z8000
Assembleur z/Architecture
ASSEMBLER/MONITOR 64
Micol Assembler
GFA Assembler
A86
MASM (Macro Assembler)
TASM (Turbo Assembler)
CIL
Jasmin
LLVM
MSIL
Parrot
P-Code (PCode)
SWEET16
G-Pascal
ASP 1.0
ASP 2.0
ASP 3.0
ASP.NET
ASP.NET Core
ABasiC (Amiga)
Adam SmartBASIC
Altair BASIC
AmigaBASIC (Amiga)
AMOS Basic (Amiga)
Atari Basic (Atari 400, 600 XL, 800, 800XL)
Basic Apple II (Integer BASIC/APPLESOFT)
Basic Commodore 64 (CBM-BASIC)
Basic Commodore 128 (BASIC 7.0)
Basic Commodore VIC-20 (CBM-BASIC 2.0)
Basic Coco 1 (Color Basic)
Basic Coco 2 (Extended Color Basic)
Basic Coco 3 (Extended Color Basic 2.0)
BASICA (PC DOS)
Basic Pro
BBC BASIC
Blitz BASIC (Amiga)
DarkBASIC
Dartmouth BASIC
GFA-Basic (Atari ST/Amiga)
GWBASIC (MS-DOS)
Liberty BASIC
Locomotive BASIC (Amstrad CPC)
MSX-Basic
Omikron Basic (Atari ST)
Oric Extended Basic
Power Basic
Quick Basic/QBasic (MS-DOS)
Sinclair BASIC (ZX80, ZX81, ZX Spectrum)
ST BASIC (Atari ST)
Turbo Basic
Vintage BASIC
VBScript
Visual Basic (VB)
Visual Basic .NET (VB .NET)
Visual Basic pour DOS
Yabasic
BeckerBASIC
SIMONS' BASIC
Basic09 d'OS-9
Disk Extended Color Basic
Basic09 d'OS-9
Disk Extended Color Basic
Access
Excel
Visual Basic pour Windows
Visual Basic .NET pour Windows
C Shell Unix (csh)
C pour Amiga
C pour Atari ST
C pour DOS
C pour Falcon030
C pour GEMDOS (Atari ST)
C pour Linux
C pour PowerTV OS
C pour OS/2
C pour Unix
C pour Windows
Aztec C
CoCo-C
GNU C
HiSoft C
IBM C/2
Introl-C
Lattice C
Microsoft C
MinGW C
MSX-C
Open Watcom C
OS-9 C Compiler
Pure C
Quick C
Turbo C
HiSoft C for Atari ST
HiSoft C for CP/M (Amstrad CPC)
C++ pour OS/2
C++ pour Windows
Borland C++
C++Builder
IBM VisualAge C++
Intel C++
MinGW C++
Open Watcom C++
Symantec C++
Turbo C++
Visual C++
Visual C++ .NET
Watcom C++
Zortech C++
C# (C Sharp) pour Windows
Apple III Cobol
Microsoft Cobol
BlueDragon
Lucee
OpenBD
Railo
Smith Project
Microsoft Fortran
WATFOR-77
CSS
FBML
Open Graph
SVG
XML
XSL/XSLT
LESS
SASS
GCJ (GNU)
JSP
Jython
Visual J++
Node.js
TypeScript
AutoLISP
ACSLogo
LotusScript pour Windows
Amiga Oberon
Oberon .NET
Apple Pascal
Delphi/Kylix/Lazarus
Free Pascal
GNU Pascal
HighSpeed Pascal
IBM Personal Computer Pascal
Lisa Pascal
Maxon Pascal
MPW Pascal
OS-9 Pascal
OSS Personal Pascal
Pascal-86
Pascal du Cray Research
Pascal/VS
Pascal-XT
PURE Pascal
QuickPascal
RemObjets Chrome
Sun Pascal
THINK Pascal
Tiny Pascal (TRS-80)
Turbo Pascal
UCSD Pascal
VAX Pascal
Virtual Pascal
Turbo Pascal for CP/M-80
Turbo Pascal for DOS
Turbo Pascal for Macintosh
Turbo Pascal for Windows
CodeIgniter (Cadre d'application)
Drupal (Projet)
Joomla! (Projet)
Phalanger (PHP .NET)
phpBB (Projet)
Smarty (balise)
Twig (balise)
Symfony (Cadre d'application)
WordPress (Projet)
Zend (Cadre d'application)
PL360
PL/M-80
PL/M-86
Turbo Prolog
CPython
IronPython
Jython
PyPy
AREXX
Regina REXX
JMP
Btrieve
Cassandra
Clipper
CouchDB
dBASE
Hbase
Hypertable
MongoDB
Redis
Access
BigQuery
DB2
H2
Interbase
MySQL
Oracle
PostgreSQL
SAP HANA
SQL Server
Sybase
U-SQL
Référence des fonctions
Routines d'interface hôte TOS
Préface
Notes légal
Dictionnaire
Recherche

Routines d'interface hôte TOS

La communication entre l'application et le DSP sur l'Atari Falcon030 doit être effectuée via un ensemble d'appels TOS fournis. La virtualisation du matériel DSP assurera la compatibilité si le matériel devait être changé dans une future machine.

Cartographie de la mémoire DSP

La RAM privée que le DSP utilise pour entreposer des données ou des programmes ne rentrant pas dans les ressources internes est fournie par trois RAM statiques de 32 Ko. Cette mémoire apparaît au DSP comme suit. L'espace programme est un bloc contigu de mots de 32 Ko. Les espaces de données X et Y sont chacun des blocs séparés de 16 Ko. Le X et Y sont accessibles, dans la carte du DSP, sous forme de blocs commençant à 0 ou 16 Ko. L'espace programme chevauche physiquement à la fois l'espace de données X et Y, de sorte que le logiciel DSP doit en tenir compte pour éviter que le programme et la mémoire de données ne se corrompent. Notez que X:0, X:16 Ko et P:16 Ko ont le même emplacement dans la mémoire physique et que Y:0, Y:16 Ko et P:0 sont également cartographiés au même emplacement physique. Les services système résideront en haut de la mémoire X avec les sous-programmes DSP. La zone BSS des sous-programmes DSP occupera les 256 premiers mots de la mémoire X et Y. Un appel de sous-programme de vidage par le programme récupérera une partie de cette mémoire pour le programme. Un appel Dsp_Available doit toujours être effectué pour déterminer la quantité de RAM libre du DSP.

Programmes DSP

Certaines étapes doivent être suivies lors de la programmation de la plateforme Atari. Certains des 32 000 mots de la mémoire DSP sont alloués aux programmes système et aux sous-programmes résidents et ne sont donc pas disponibles pour une utilisation par le programme DSP. Un processus hôte doit donc effectuer un appel Dsp_Available pour connaître la quantité de mémoire restante pour son programme DSP. Si la quantité est satisfaisante, le processus hôte doit réserver cette zone de mémoire à l'aide d'un appel Dsp_Reserve. Cet appel empêchera la mémoire du programme d'être corrompue par le système. Il est également nécessaire que le processus hôte empêche l'accès au DSP par un autre processus hôte en effectuant un appel Dsp_Lock. Cet appel doit venir avant tout autre appel pour manipuler le DSP. Cela garantira que l'état du DSP ne sera pas modifié par quelqu'un d'autre pendant que l'application l'utilise. Lorsque le processus hôte utilise le programme DSP, il doit effectuer un appel Dsp_Unlock pour permettre à d'autres processus d'utiliser le DSP. Si un appel à Dsp_Lock renvoie une valeur «DSP busy», le processus hôte doit attendre avant d'effectuer des appels système DSP jusqu'à ce qu'un Dsp_Lock réussi puisse avoir lieu. Le non-respect de ces règles entraînera de mauvais résultats imprévisibles lors de la communication avec le DSP. Avant d'effectuer un appel de déverrouillage, l'application hôte doit s'assurer que le processus DSP a restauré l'IPR (X:$FFFF) et le MR à leur état d'origine.

Sous-programmes DSP

L'existence de sous-programmes DSP permet au système d'avoir plusieurs processus DSP résidents en même temps. Cela économise au système le temps de charger chaque programme dans le DSP chaque fois qu'il doit être utilisé. Ces sous-programmes resteront résidents dans le DSP jusqu'à ce qu'ils soient expulsés par d'autres sous-programmes ou vidés par un programme DSP souhaitant plus de mémoire. Les sous-programmes DSP sont soumis à beaucoup plus de contraintes et de restrictions que les programmes DSP. Le code de sous-programme doit être complètement déplaçable. Lors de l'écriture du code de sous-programme, les instructions doivent commencer à l'adresse 0. Lorsqu'un sous-programme est appelé via une commande hôte, le sous-programme peut obtenir son registre PC de démarrage via le port hôte. Cet emplacement de début étant envoyé par TOS doit être lu par la taille du sous-programme est limité à 1024 mots d'instructions DSP. Tout ce qui est plus grand serait probablement plus correctement exécuté en tant que programme. Le code sera déplacé quelque part dans la mémoire RAM du DSP externe. Il faut prendre soin de faire relocaliser toutes les adresses utilisées dans le programme (adresses de fin pour les boucles do par exemple) en se basant sur le compteur du programme d'origine. Toutes les données initialisées doivent être déclarées dans l'espace programme dans lequel elles sont contenues. Un bloc de mémoire X et Y a été mis de côté pour un espace variable non déclaré de sous-programmes. Cette zone est située dans les 256 mots de mémoire DSP les plus élevés de l'espace mémoire X et Y (X:3F00 - X:3FFF). Cette zone peut être utilisée librement par le sous-programme mais comme cette zone est utilisée par tous les sous-programmes, il ne faut pas supposer que la mémoire sera préservée la prochaine fois que le sous-programme s'exécutera. Les programmes hôtes doivent utiliser la fonction Dsp_Lock avant d'exécuter un sous-programme DSP. Étant donné que les sous-programmes DSP sont exécutés sous forme d'interruptions via les commandes hôtes envoyées par le système, ils doivent être interrompus par un RTI après la fin de son exécution. Le sous-programme ne doit assumer aucun état initial du DSP puisque son état est déterminé par des programmes et sous-programmes précédemment exécutés et non à partir d'un ensemble de démarrage. Une séquence typique d'appels pour exécuter un sous-programme peut ressembler à ce qui suit :

  1. if(!Dsp_Lock()) {
  2.   ability = Dsp_RequestUniqueAbility();
  3.   handle = Dsp_LoadSubroutine(ptr,size,ability);
  4.   status = Dsp_RunSubroutine(handle);
  5.   Dsp_DoBlock(data_in,size_in,data_out,size_out);
  6.   Dsp_Unlock();
  7. }

Une manière plus efficace d'exécuter le sous-programme serait de vérifier d'abord si un sous-programme existe déjà sur le DSP satisfaisant aux exigences de l'application :

  1. if(!Dsp_Lock()) {
  2.   handle = Dsp_InqSubrAbility(ability);
  3.   if(handle) {}
  4.     status = Dsp_RunSubroutine(handle);
  5.     Dsp_DoBlock(data_in,size_in,data_out,size_out);
  6.     Dsp_Unlock();
  7.   }
  8. }

Capacité du programme

La capacité d'un programme (et d'un sous-programme) doit être signalée au système lors du chargement du processus DSP. Cette capacité est soit une capacité prédéfinie ayant été officiellement enregistrée auprès d'Atari, soit une capacité unique ayant été acquise par un appel Dsp_RequestUniqueAbility. Cette capacité peut être utilisée pour déterminer si l'hôte a besoin de recharger son processus DSP ou s'il peut utiliser un processus existant déjà à bord du DSP. Le concept de base de l'interface hôte est que les programmes et sous-programmes DSP n'appartiennent pas à l'application hôte les ayant chargés. Une fois chargés, les programmes DSP deviennent partagés et librement utilisables par toute application hôte souhaitant les utiliser.



PARTAGER CETTE PAGE SUR
Dernière mise à jour : Samedi, le 17 avril 2021