Menù principale

Notizie  Grafica  Forum  Links  Retro Trailer  Recensioni  Modelli Amiga  Storia Amiga  Retro-Gamers  Lista Utenti  Contatti  Policy sito

Login

Nick Password

Registrati - Recupera dati

09 Aprile 2020 Postato da: AMG_Novice_Usr Programmazione su Amiga mediante processi concorrenti o threads

Buongiorno a tutti, vorrei avere da voi un parere su una questione di programmazione. Mi sto dilettando, con velleità del tutto ludico-didattiche, a fare qualche programmino su Linux, per essere precisi su Raspberry PI 3, quindi la distro è Raspbian (flavour di Debian), e la mia curiosità è la seguente: è possibile su Amiga fare le stesse cose, magari sempre in C, oppure in Basic … non so. Al di là del linguaggio, mi interessa sapere se/come poter implementare lo stesso funzionamento. Entriamo un po' più nel dettaglio: date un'occhiata ai seguenti due links (nel primo ci metto il file C sorgente da compilare con GCC da riga di comando, il secondo link è soltanto l'eseguibile.exe già compilato, lo metto solo se qualcuno volesse prima provarlo, su un Raspberry): https://drive.google.com/file/d/12plXZBq4FHia MpMXoWE98020cTWx_P9t/view https://drive.google.com/file/d/1d6ZRaa30-Z5F mZIsW-ui8SnKvrIs3COL/view Come potere vedere, faccio delle cose molto semplici, ovvero chiamo una fork, dopo la quale avrò, a run-time, un processo padre ed un processo figlio 1, e poi una seconda fork, da cui il processo padre ed un processo figlio 2, quindi abbiamo 3 processi, con 3 PID diversi, 3 processi concorrenti (stessa priorità? non so … eventualmente in Linux come si fa ad assegnare la priorità ad un processo?). Ciascuno di questi 3 processi incrementa un contatore "accessi", stampa a video il valore corrente del suo contatore, esegue la stessa stampa su un file.txt. I 3 processi devono essere sincronizzati tramite un semaforo, il quale viene creato grazie alla memoria condivisa (libreria shm.h): un byte di shared memory viene creato e messo a disposizione di tutti e 3 i processi, quindi questi si sincronizzano fra di loro leggendo da/scrivendo su questo semaforo fatto in casa. La sincronizzazione è importante per consentire un accesso alternato/ordinato sia allo standard-output (il video della shell) sia al file.txt. Processo Padre: contatore = 1 Processo figlio1: contatore = 1 Processo figlio2: contatore = 1 Processo Padre: contatore = 2 Processo figlio1: contatore = 2 Processo figlio2: contatore = 2 Processo Padre: contatore = 3 Processo figlio1: contatore = 3 Processo figlio2: contatore = 3 ecc... fino a 10 Non ci devono essere intrecciamenti, battimenti, casini diciamo … il sincronismo deve dare questo risultato, sia a video che sul file.txt. In effetti tutto funziona perfettamente (provate … potete GCC-compilare il sorgente su qualunque piattaforma che abbia Linux). La mia domanda quindi è: vorrei fare la stessa cosa su Amiga. Come fare? Amiga è un sistema multi-tasking, quindi mi aspetto di poter anche qui far fare una fork ad AmigaOS e gestire in modo sincronizzato dei processi, esattamente come fatto con Linux. Vorrei inoltre che mi suggeriate degli ambienti in cui sviluppare, possibilmente in C, queste cose. Avevo sentito parlare di Lattice C, ovvero un compilatore (4 floppy disk) per C su Amiga. è disponibile qualcosa del genere, magari che si possa installare su HDD di un Amiga 1200? Ci sono alternative? Grazie

Commenti: 20  Aggiungi  - Leggi

Indice: forum / Richieste di Aiuto

utente amiga quadratico medio Post inviati: 701 Commento 1 AMG_Novice_Usr 9 Aprile 2020    12:56:26 La stessa cosa di prima può essere fatta anche in questo modo: https://drive.google.com/file/d/1jYO4GMp1_qxxE1hfy j0kGuAkp5SRP7t9/view https://drive.google.com/file/d/1oHHIJ8kigxEg-Zvf0 WDewN_lJCQX7kAi/view Guardate solo il primo link, poiché al solito il secondo è il compilato. Come vedete, adesso non ci sono 3 processi, bensì 3 threads, sincronizzati tramite un semaforo fatto in casa: stavolta non c'è bisogno di scomodare la memoria condivisa, è sufficiente una semplice variabile che ho chiamato SEM, dal momento che sono threads, non processi, quindi condividono le variabili, lo spazio di indirizzamento, tutto. La mia domanda è: è possibile fare la stessa cosa con Amiga? Amiga li gestisce i threads, oppure va solo a processi? Curiosità: per chi avesse dimestichezza con OS per applicazioni embedded, su microcontrollori abbastanza "piccoli", sto parlando soprattutto dell'OS "FreeRTOS" (un OS che gira su una quarantina di microcontrollori diversi, di vari vendors, quali ST, Atmel, Microchip, NXP ecc ...): beh, lì ad esempio esiste una chiamata di sistema per installare/lanciare un processo, un task, ed un'altra per lanciare una "coo-routine", nome che indica una specie di thread. A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 Post inviati: 1986 Commento 2 schiumacal 9 Aprile 2020    13:56:43 Non ho visto i sorgenti perche' non avrei comunque il tempo per studiarli. Comunque cerchero' di rispondere alla tua domanda, anche se non ho mai lavorato su Rasp. Il Sistema Operativo di Amiga, ha differenza di molti altri OS, ha una gestione dei processi di tipo Preempitive. (Considera che un OS del genere nato a meta' degli anni '80, pensato per ambiente Home, era avanti di secoli rispetto a tutti gli altri OS). Amiga OS da questo punto di vista, ancora oggi non ha rivali. Pensa ad esempio ad un Amiga 1000 che con soli 256Kbyte di RAM riusciva a gestire tranquillamente diversi processi contemporaneamente senza andare in Tilt. Comunque per ritornare al tuo discorso, AmigaOS, ovviamente essendo Multitasking Preempitive gestisce gia' in automatico qualsiasi tipo di Thread in modalità concorrente, lasciando la gestione dei processi direttamente alla CPU. Il problema e' capire come vorresti lavorare su Amiga. Perche' il suo hardware e' stato progettato per eseguire compiti separati e cercare di evitare al minimo problemi di conflitti di memoria, proprio per il fatto che e' un OS Multitasking Preempitive. Ad esempio la gestione della memoria riservata alla grafica e' separata dalla gestione della memoria riservata all'uso normale di un elaboratore. E questo per evitare conflitti nel caso in cui due processi provino a condividere le stesse posizioni di memoria. Un Rasp non credo che abbia al suo interno questo tipo di separazione hardware. In conclusione realizzare con Amiga quello che tu fai normalmente con Rasp, ovvio che puoi farlo, e forse anche meglio, ma dovresti lasciare ad AmigaOS la gestione della concorrenza, altrimenti potresti baypassare totalmente l'OS scrivendo codice in linguaggio macchina, ma in questo caso dovresti stare molto attento alla gestione delle sincronizzazioni, che non e' proprio semplicissimo farle su Amiga rispetto ad un Rasp, per quanto non conosco come si lavori su Rasp. Una domanda ? Perche' chiedi di voler fare cose del genere con Amiga, quando con un Rasp le realizzi in un microsecondo ? Un giorno o l'altro risolverò equazioni di grado superiore a cinque. http://www.schiumacal.altervista.org/ Boss Post inviati: 2858 Commento 3 Boss 9 Aprile 2020    18:09:34 scusa @schiumacal, ma cosa cambia dal punto di vista della programmazione usare un raspberry (ARM) e usare un pc (x86-x64) se in entrambi i contesti si utilizza linux? le architetture sono diverse ma i meccanismi di programmazione e il linguaggio è lo stesso per entrambi, quindi in teoria se è giusto ciò che dico anche se non hai un raspberry sai programmare per esso, perchè utilizzi linux su pc. giusto? A1200/030, APOLLO 1230LC 8MB KICK 3.1 HDD IDE 40GB df1 esterno RECAPPATA 100% || A1200 8MB FAST CF 4 GB RECAPPATA 100% || A500+ CON A501 switch df0 df1 nascosto e gotek esterno (RIPARATE DA ACIDO) A1200 x64 x5-z8350 4GB RAM con floppy Mod || A500 x64 i5 8GB RAM (Toshiba portege r830)(windows 7) || A2000 X64 Socket 775 XEON E5450 771 MOD 8GB RAM TRIPLE BOOT (WINUAE A4000 AFAOS / WIN7 / UBUNTU) Commodore 8296 con tastiera, drive 8250lp e stampate ad aghi tutto funzionante Post inviati: 1986 Commento 4 schiumacal 9 Aprile 2020    19:25:32 Citazione scusa @schiumacal, ma cosa cambia dal punto di vista della programmazione usare un raspberry (ARM) e usare un pc (x86-x64) se in entrambi i contesti si utilizza linux? le architetture sono diverse ma i meccanismi di programmazione e il linguaggio è lo stesso per entrambi, quindi in teoria se è giusto ciò che dico anche se non hai un raspberry sai programmare per esso, perchè utilizzi linux su pc. giusto? Non proprio. Posso saper programmare, ok, ma non ho mai messo mani su un Rasp, quindi non ne conosco il suo funzionamento a priori, e se non mi documento per bene, non potrei mai lavorarci sopra. Voglio dire, un conto e scriverci quattro righe di comando per far uscire la scritta "Ciao mondo" in C++ sotto Linux, un conto e lavorare con la programmazione concorrente per la gestione di sincronismi sui diversi thread. AMG_Novice_Usr chiedeva di sincronizzare dei thread utilizzando la programmazione concorrente, robba mica da poco se volessi effettuarla su un Amiga, ma anche fosse un PC qualsiasi... Questi ultimi, infatti hanno degli OS gia' configurati per la gestione di tutto l'hardware, senza che se ne occupi il programmatore. Ad esempio AmigaOS e' fatto in modo che sia la CPU a decidere quanto tempo dare ad ogni Thread per lavorare in multitasking, non deve occuparsi di questo il programmatore di turno, altrimento vorrebbe dire dover riscrivere parti di un OS exnovo. Se AMG_Novice_Usr spiegasse meglio cosa vuole ottenere con l'Amiga, potrei essere più preciso a riguardo. Citazione Come potere vedere, faccio delle cose molto semplici, ovvero chiamo una fork, dopo la quale avrò, a run-time, un processo padre ed un processo figlio 1, e poi una seconda fork, da cui il processo padre ed un processo figlio 2, quindi abbiamo 3 processi, con 3 PID diversi, 3 processi concorrenti (stessa priorità? non so … eventualmente in Linux come si fa ad assegnare la priorità ad un processo?). Ciascuno di questi 3 processi incrementa un contatore "accessi", stampa a video il valore corrente del suo contatore, esegue la stessa stampa su un file.txt. I 3 processi devono essere sincronizzati tramite un semaforo, il quale viene creato grazie alla memoria condivisa (libreria shm.h): un byte di shared memory viene creato e messo a disposizione di tutti e 3 i processi, quindi questi si sincronizzano fra di loro leggendo da/scrivendo su questo semaforo fatto in casa. La sincronizzazione è importante per consentire un accesso alternato/ordinato sia allo standard-output (il video della shell) sia al file.txt. Di che processi parliamo ? Qui stiamo parlando di strutture software accademiche che vengono sviluppate come esercizi in università in ambiente UNIX. http://homes.dsi.unimi.it/~boccignone/GiuseppeBoccignone_webpage/Sistemi_Operativi_2010_files/SOLez19_SHMx4.pdf Se Amiga non gestisce la libreria "shm.h" come si puo' realizzare facilmente un esercizio del genere ? Commento modificato il 09/04/2020 alle ore 19:28:37 Un giorno o l'altro risolverò equazioni di grado superiore a cinque. http://www.schiumacal.altervista.org/ utente amiga quadratico medio Post inviati: 701 Commento 5 AMG_Novice_Usr 10 Aprile 2020    15:23:15 Citazione Non ho visto i sorgenti perche' non avrei comunque il tempo per studiarli Sono poche righe, e per rispondere alla domanda che titola la discussione temo che quei sorgenti vadano scorsi, almeno a grandi linee … ad ogni modo … facciamo così: cerco di scrivere davvero 4 righe di pseudo-codice. Citazione … anche se non ho mai lavorato su Rasp Non importa di aver lavorato o meno su Rasp: i miei sorgenti che trovi nella discussione sono compilabili in ambiente GNU/Linux su qualunque piattaforma HW … io stesso li ho provati (stesso funzionamento che trovo su Rasp-ARM) anche su un MacMini G4 PowerPC, dove gira Lubuntu 12.04 LTS … e se li compili per un x86 oppure un x64, otterrai lo stesso identico comportamento … nei sorgenti trovi la scrittura alternata e non intrecciata ("semaforica") che 3 processi (o 3 threads, nel secondo esempio) fanno sullo "stdout" (video) e su un file aperto con "fopen(...)", quindi stiamo parlando di cose che per te programmatore sono HW-insensitive … ti è del tutto trasparente, massima portabilità da un HW all'altro … poi è chiaro che se pretendi di usare la porta I2C o quella SPI di Rasp, ovviamente il risultato ottenuto non è trasportabile su un x86/x64, semplicemente perché questi HWs non hanno quelle porte! Citazione Il Sistema Operativo di Amiga, ha differenza di molti altri OS, ha una gestione dei processi di tipo Preempitive Non pretendo risposte universitarie, gli OS sono un universo, tuttavia sarei curioso di sapere qualcosa in più sulla politica di prelazione della CPU implementata da AmigaOS … di che politica stiamo parlando? E come agisce il reskeduler di AmigaOS? Esiste, inoltre, una differenziazione fra short-term e long-term reskeduler? In buona sostanza, lo short-term reskeduler esiste (ovviamente) … ma come agisce? A furto di ciclo (politica "round-robin")? Il time-sharing fra processi è equi-partizionato, quindi abbiamo una time-slice di … sparo a caso … 10ms per ogni processo attivo? Oppure abbiamo una politica di short-term reskeduling un po' più evoluta (come ad esempio in Linux oppure in Windows)? Ci sono OS embedded (es: FreeRTOS) dove la prelazione non è frutto di una "decisione" presa dall'OS, bensì è frutto di una time-slice statica assegnata ad ogni singolo task. Se ad esempio installi, da tuo programma, un processo Task1, puoi assegnargli una time-slice di 10ms, poi magari installi anche un secondo processo Task2, e a questo assegni una time-slice di 5ms, quindi il secondo ha una priorità minore rispetto al primo, poiché ciascun task, finchè non è esaurita la sua time-slice, non consente al reskeduler di assegnare la CPU ad un altro processo. A meno che il processo in corso non faccia una "idle" (yield, come si dice in FreeRTOS), chiamata di sistema con la quale l'OS viene informato che il task attuale ha finito il suo lavoro prima dello scadere della sua time-slice, quindi l'OS può avvantaggiarsi e fare subito la prelazione della CPU (questo è il cosiddetto sistema "cooperativo" degli OS). Amiga OS è cooperativo? Esiste inoltre il long-term reskeduler? Quindi esiste una swap-area (in Rasp esiste) capace di ospitare segmenti di processi (pezzi di codice e/o set di dati di processi), processi che sono NOT Ready, magari perché bloccati su qualche semaforo, quindi il long-term-reskeduler di AmigaOS li parcheggia in swap-area, quindi su HDD oppure sul floppy disk del WB, ma comunque non certo in RAM, poiché la RAM serve ad altri processi, loro si attivi e non bloccati su alcun semaforo … ecco … mi interessa molto far chiarezza su tutte queste cose. Anche se, riflettendoci, mi pare che le CPU tipo la 68000 - 68020 - 68EC020, non hanno la MMU, quindi non esiste in questi ambienti il concetto di memoria virtuale, quindi un processo non ha la possibilità di essere, in parte, parcheggiato sull'HDD (in parte in RAM ed in parte sulla memoria di massa, oppure tutto in memoria di massa, poiché il processo in questione è bloccato da tempo). Citazione Il problema e' capire come vorresti lavorare su Amiga. Molto semplicemente, fare in ambiente "Lattice C" (se conoscete altri IDE per Amiga, che supportino C o meglio ancora C++, fatemi sapere), un bel main.c … facciamo così … questo è lo pseudo-codice di cui sopra, lo metto nel prossimo post A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 utente amiga quadratico medio Post inviati: 701 Commento 6 AMG_Novice_Usr 10 Aprile 2020    15:32:41 ///////////////// mio programmino per Amiga /////////////////// int counter1=0, counter2=0, counter3=0; void processo1(void) { wait(); counter1++; printf("Processo1: %6d",counter1); // stampa a video di counter1 attuale signal(); } void processo2(void) { wait(); counter2++; printf("Processo2: %6d",counter2); // stampa a video di counter2 attuale signal(); } void processo3(void) { wait(); counter3++; printf("Processo3: %6d",counter3); // stampa a video di counter3 attuale signal(); } int main(void) { // facciamo una fork: lanciamo 3 processi concorrenti, magari un padre e 2 figli install_task(processo1,flags); install_task(processo2,flags); install_task(processo3,flags); return 0; } A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 utente amiga quadratico medio Post inviati: 701 Commento 7 AMG_Novice_Usr 10 Aprile 2020    15:33:32 purtroppo qui l'indentazione sembra non funzionare ... A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 utente amiga quadratico medio Post inviati: 701 Commento 8 AMG_Novice_Usr 10 Aprile 2020    15:46:07 Citazione Un Rasp non credo che abbia al suo interno questo tipo di separazione hardware. Ha il suo grado di separazione HW: Rasp PI 3 possiede 4 CPU indipendenti ed una CPU grafica (GPU). Esiste un frame-buffer in SDRAM per la grafica, accessibile dalla GPU (credo anche dalle 4 CPU), non so sull'arbitraggio come funziona (questa RAM funge da chip-ram, diciamo). Citazione dovresti lasciare ad AmigaOS la gestione della concorrenza Si certo, nel senso che sarà AmigaOS (o meglio, il reskeduler facente parte di Exec, il microkernel di AmigaOS) a schedulare i miei processi: processo1 processo2 processo3 Però tramite segnali, oppure tramite un byte di ram condivisa (???), oppure tramite semafori (???) avrei bisogno che quando processo1 fa fatto i suoi comodi, deve dire "ho finito", e bloccarsi; a questo punto si sblocca processo2, che fa il suo lavoro, poi dice anche lui "ho finito", bloccandosi … insomma … il tutto ciclicamente e circolarmente. Quindi, reskeduling fatto da AmigaOS (ovviamente), ma sincronismo fatto da me con della semaforica (il semaforo protegge l'echo su schermo oppure un file di testo, insomma la risorsa acceduta dai processi). Citazione Perche' chiedi di voler fare cose del genere con Amiga, quando con un Rasp le realizzi in un microsecondo ? Per imparare A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 Post inviati: 1986 Commento 9 schiumacal 10 Aprile 2020    15:55:31 Capito... AmigaOS non e' cooperativo, come ti ho gia' detto sopra, e' un OS preemptive. Quindi non sono i task a decidere il tempo che devono occupare loro in cicli di clock, ma e' la CPU che detta legge. Detto questo e osservando un po' il tuo pseudo-codice (purtroppo non c'e' l'identazione sul nostro forum...), quello che vuoi fare, penso puoi farlo tranquillamente. Gli IDE per sviluppare in C++ con Amiga ci sono, ma sono tutti pacchetti a pagamento. Posso consigliarti lo StormC++ ver 3.0. Questo e' l'ultimo pensato per CPU cisc, quindi motorola 68xxx. Io l'ho usato tranquillamente, sono 8 floppy piu' un manuale in .pdf di circa 300 pagine. Credo sia il migliore se vuoi sviluppare in C++ per Amiga Classic. Mandami un mp che ti spiego una cosa Un giorno o l'altro risolverò equazioni di grado superiore a cinque. http://www.schiumacal.altervista.org/ utente amiga quadratico medio Post inviati: 701 Commento 10 AMG_Novice_Usr 10 Aprile 2020    16:02:51 Citazione scusa @schiumacal, ma cosa cambia dal punto di vista della programmazione usare un raspberry (ARM) e usare un pc (x86-x64) se in entrambi i contesti si utilizza linux? le architetture sono diverse ma i meccanismi di programmazione e il linguaggio è lo stesso per entrambi, quindi in teoria se è giusto ciò che dico anche se non hai un raspberry sai programmare per esso, perchè utilizzi linux su pc. giusto? Si, sono d'accordo. Esempio banale: // inizio programma #include <stdio.h> FILE* fp=NULL; char stringa [32] ="stringa ASCII …n"; int main(void) { fp = fopen("… path … mio_file1.txt", "w"); // apro in scrittura quel file, pulendolo prima; se non esiste, lo creo fwrite(stringa, strlen(stringa), 1, fp); // ci scrivo dentro la stringa fino al LF incluso fclose(fp); // chiudo il file return 0; } // fine programma Questo codicino lo posso GCC-compilare sia per Lubuntu su Mac/PowerPC, sia per Ubuntu su x86, sia per Xubuntu su Rasp/ARM. Sarà compito della libreria stdio.h rendermi la cosa trasparente. Chi ha realizzato questa libreria per ciascuna delle 3 architetture, ha lavorato in modo che per me sia sufficiente chiamare fopen, fwrite, fread ecc … non devo fare altro, tutto il resto è risolto a basso livello. Confido che anche in Lattice C per Amiga ci sia una libreria stdio.h che mi consenta di fare le stesse cose con la stessa sintassi. A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 Post inviati: 1986 Commento 11 schiumacal 10 Aprile 2020    16:48:04 Citazione Citazione scusa @schiumacal, ma cosa cambia dal punto di vista della programmazione usare un raspberry (ARM) e usare un pc (x86-x64) se in entrambi i contesti si utilizza linux? le architetture sono diverse ma i meccanismi di programmazione e il linguaggio è lo stesso per entrambi, quindi in teoria se è giusto ciò che dico anche se non hai un raspberry sai programmare per esso, perchè utilizzi linux su pc. giusto? Si, sono d'accordo. Esempio banale: // inizio programma #include <stdio.h> FILE* fp=NULL; char stringa [32] ="stringa ASCII …n"; int main(void) { fp = fopen("… path … mio_file1.txt", "w"); // apro in scrittura quel file, pulendolo prima; se non esiste, lo creo fwrite(stringa, strlen(stringa), 1, fp); // ci scrivo dentro la stringa fino al LF incluso fclose(fp); // chiudo il file return 0; } // fine programma Questo codicino lo posso GCC-compilare sia per Lubuntu su Mac/PowerPC, sia per Ubuntu su x86, sia per Xubuntu su Rasp/ARM. Sarà compito della libreria stdio.h rendermi la cosa trasparente. Chi ha realizzato questa libreria per ciascuna delle 3 architetture, ha lavorato in modo che per me sia sufficiente chiamare fopen, fwrite, fread ecc … non devo fare altro, tutto il resto è risolto a basso livello. Confido che anche in Lattice C per Amiga ci sia una libreria stdio.h che mi consenta di fare le stesse cose con la stessa sintassi. Ti ho gia' inviato un mp. Per il resto del discorso, come avevo gia' detto, e' ovvio che sviluppare in C del semplice codice come quello che hai descritto tu ora, risulta uguale per qualsiasi sistema. Beh! diciamo proprio ovvio no, anche perche' esistono piccole differenze di programmazione tra i vari OS, ma anche tra i vari IDE di sviluppo in C. Ad esempio: in modalita' "console-application" prova un po' a cambiare semplicemente il colore dello sfondo dei font sotto Windows e sotto Linux, i comandi sono leggermente diversi. Oppure prova a pulire lo schermo e ad abilitare una risoluzione diversa... comandi ovviamente diversi tra Windows e Linux. Oppure ancora, prova a sviluppare applicazioni con migliaia di righe di comando in DevC++ e lo stesso sorgente prova a ricompilarlo con CodeBlocks... sara' un inferno... Un giorno o l'altro risolverò equazioni di grado superiore a cinque. http://www.schiumacal.altervista.org/ Temibile Pirata Post inviati: 2144 Commento 12 SukkoPera 10 Aprile 2020    17:15:02 Non capisco perché ti ostini a ripetere che AmigaOS sia un OS a multitasking preemptivo. All'epoca era sicuramente una cosa relativamente nuova ed innovativa, soprattutto in ambito home computer, ma oggi praticamente TUTTI i sistemi operativi contemporanei lo sono, dovrebbe essere cosa nota a qualunque programmatore moderno. In ogni caso stiamo parlando di meccanismi per sincronizzare processi, che sicuramente possono (devono?) esistere sia negli OS preemptivi che in quelli cooperativi e che non dovrebbero essere influenzati dai meccanismi che l'OS (non la CPU, che di suo non sa fare niente!) usa dietro le quinte (ad esempio i software scritti per Windows 3.1 giravano tranquillamente su Windows 95, forse ancora sui Windows di oggi!). Anche la particolare architettura Amiga interessa poco in questo contesto, visto appunto che vogliamo lasciare fare il lavoro sporco all'OS e non programmare direttamente l'hardware. Serve solo trovare un meccanismo di IPC. Non sono esperto di programmazione su Amiga, ma sicuramente supporta le pipe, e queste possono sicuramente essere usate per implementare dei semafori, quindi la cosa è sicuramente fattibile almeno in questo modo. La presenza di stadio.h e di tutti gli altri header "famosi", nonché la conformità di tutte le funzioni di libreria dipendono dallo standard a cui si conforma il compilatore, tipo K&R, ANSI o C99 (O C++11, ecc...). Questa sarebbe una delle prime cose da capire, in modo da sapere quali funzioni vengono messe a disposizione. Se si fatica a compilare con CodeBlocks codice scritto con DevC++ è perché non si è fatta abbastanza attenzione a questo aspetto e si sono usate librerie specifiche del compilatore (aspetto di cui i programmatori Windows si curano sempre poco). Il mondo è pieno di codice che compila con compilatori diversi anche su sistemi operativi diversi (basti pensare al kernel Linux, o GCC!), basta avere questo tra gli obiettivi e comportarsi di conseguenza. A proposito, esiste anche un porting di GCC per Amiga (che è almeno C99), e una libreria che implementa l'interfaccia POSIX, rendendo quindi possibili praticamente tutte le system call tipiche di Unix. Tra queste ce ne sono un tot per implementare anche un meccanismo di shared memory (di cui non sono pratico, sorry). Ci sono anche delle versioni per cross-compiling (ad esempio SysTest/ATK viene sviluppato in questo modo). Commento modificato il 10/04/2020 alle ore 17:17:26 I miei progetti Retrogaming Post inviati: 1986 Commento 13 schiumacal 10 Aprile 2020    20:13:47 Citazione Non capisco perché ti ostini a ripetere che AmigaOS sia un OS a multitasking preemptivo. E' una semplice risposta che ho dato ad AMG_Novice_Usr, perche' me lo ha chiesto qui... Citazione Amiga OS è cooperativo? Nel un suo Commento numero 5 Citazione In ogni caso stiamo parlando di meccanismi per sincronizzare processi, che sicuramente possono (devono?) esistere sia negli OS preemptivi che in quelli cooperativi e che non dovrebbero essere influenzati dai meccanismi che l'OS (non la CPU, che di suo non sa fare niente!) usa dietro le quinte (ad esempio i software scritti per Windows 3.1 giravano tranquillamente su Windows 95, forse ancora sui Windows di oggi!). Anche la particolare architettura Amiga interessa poco in questo contesto, visto appunto che vogliamo lasciare fare il lavoro sporco all'OS e non programmare direttamente l'hardware. Inizialmente non avevo ben compreso quello che voleva realizzare, pensavo volesse creare sincronizzazioni tra processi gestiti in parallelo baypassando il Sistema Operativo. Poi ho chiesto ulteriori spiegazioni e tutto e' stato piu' chiaro. Ovviamente, per sviluppare software relativo alla programmazione concorrente, esistono linguaggi moderni: - Erlang - Dart - Go Il campo della programmazione concorrente e della programmazione in parallelo, non sono certamente argomenti semplici da affrontare. Per questo esiste una materia da studiare per un anno ai corsi di laurea in Informatica nelle Universita'. Ps. L'Informatica comprende una vastissima gamma di applicazioni. Personalmente l'ho sempre paragonata alla Medicina. Cosi come esiste un chirurgo che puo' operare al cuore, perche' e' il campo devo si e' specializzato, esiste anche un chirurgo che puo' effettuare operazioni di plastica facciale... ognuno ha un suo campo di specializzazione ben differente, pur essendo entrambi eccellenti nella branca della chirugia. Anche l'Informatica e' cosi. C'e' lo specialista che sviluppa kernel, c'e' quello che sviluppa game, c'e' quello che lavora sul Web, ecc.ecc. Citazione Serve solo trovare un meccanismo di IPC. Non sono esperto di programmazione su Amiga, ma sicuramente supporta le pipe, e queste possono sicuramente essere usate per implementare dei semafori, quindi la cosa è sicuramente fattibile almeno in questo modo. Se per questo, potrebbe anche realizzarlo in Basic. Non e' una cosa complicata, l'importante e' elaborare il giusto algoritmo che riesce nell'intento. Ovviamente bisogna essere uno sviluppatore con la mente abbastanza aperta. E credimi, non sempre e' facile trovarne uno che possa essere realmente definito tale. Citazione La presenza di stadio.h e di tutti gli altri header "famosi", nonché la conformità di tutte le funzioni di libreria dipendono dallo standard a cui si conforma il compilatore, tipo K&R, ANSI o C99 (O C++11, ecc...). Questa sarebbe una delle prime cose da capire, in modo da sapere quali funzioni vengono messe a disposizione. Se si fatica a compilare con CodeBlocks codice scritto con DevC++ è perché non si è fatta abbastanza attenzione a questo aspetto e si sono usate librerie specifiche del compilatore (aspetto di cui i programmatori Windows si curano sempre poco). Il mondo è pieno di codice che compila con compilatori diversi anche su sistemi operativi diversi (basti pensare al kernel Linux, o GCC!), basta avere questo tra gli obiettivi e comportarsi di conseguenza. Forse volevi dire stdio.h. Se si fatica a compilare con Codeblocks codice scritto con DevC++ e' solo perche' il DevC++ oltre che essere un IDE stravecchio e non piu' aggiornato da secoli, era gia' a suo tempo pieno di Bug. Fidati... cio' lavorato per due anni pieni, prima di buttarlo nella spazzatura. DevC++ capitava spesso che dava risultati diversi da macchina a macchina, senza un senso... Oddio il senso c'era, ma starlo a spiegare in questo contesto non mi pare proprio il caso. Ps. @ AMG_Novice_Usr Ti rispondo ora in pm, scusami che oggi sto' un po' impegnato e non sempre riesco a leggere e rispondere sempre velocemente. Commento modificato il 10/04/2020 alle ore 22:31:27 Un giorno o l'altro risolverò equazioni di grado superiore a cinque. http://www.schiumacal.altervista.org/ Temibile Pirata Post inviati: 2144 Commento 14 SukkoPera 10 Aprile 2020    23:30:47 Citazione Inizialmente non avevo ben compreso quello che voleva realizzare, pensavo volesse creare sincronizzazioni tra processi gestiti in parallelo baypassando il Sistema Operativo. Poi ho chiesto ulteriori spiegazioni e tutto e' stato piu' chiaro. Ovviamente, per sviluppare software relativo alla programmazione concorrente, esistono linguaggi moderni: - Erlang - Dart - Go Il campo della programmazione concorrente e della programmazione in parallelo, non sono certamente argomenti semplici da affrontare. D'accordo, ma secondo me hai un po' frainteso l'entità della cosa. Quello che l'OP vuole fare è semplicemente un classico esercizio di Sistemi Operativi, comune nello studio della materia. Citazione L'Informatica comprende una vastissima gamma di applicazioni. Personalmente l'ho sempre paragonata alla Medicina. Cosi come esiste un chirurgo che puo' operare al cuore, perche' e' il campo devo si e' specializzato, esiste anche un chirurgo che puo' effettuare operazioni di plastica facciale... ognuno ha un suo campo di specializzazione ben differente, pur essendo entrambi eccellenti nella branca della chirugia. Anche l'Informatica e' cosi. C'e' lo specialista che sviluppa kernel, c'e' quello che sviluppa game, c'e' quello che lavora sul Web, ecc.ecc. Questo è poco ma sicuro . Io di come fare grafica, ad esempio, non so assolutamente niente! L'ultima volta che sono riuscito a disegnare un triangolo che si muoveva ero straesaltato! Citazione Se per questo, potrebbe anche realizzarlo in Basic. Non e' una cosa complicata, l'importante e' elaborare il giusto algoritmo che riesce nell'intento. Ovviamente bisogna essere uno sviluppatore con la mente abbastanza aperta. E credimi, non sempre e' facile trovarne uno che possa essere realmente definito tale. Non credo che esista un basic che permetta di sfruttare pipe o altri meccanismi IPC, ma potrei sbagliarmi. È una cosa che non è proprio... basic, quindi non mi aspetto di trovarla in questo linguaggio. Citazione Forse volevi dire stdio.h. Ovviamente, dannato autocorrettore! Citazione Se si fatica a compilare con Codeblocks codice scritto con DevC++ e' solo perche' il DevC++ oltre che essere un IDE stravecchio e non piu' aggiornato da secoli, era gia' a suo tempo pieno di Bug. Fidati... cio' lavorato per due anni pieni, prima di buttarlo nella spazzatura. DevC++ capitava spesso che dava risultati diversi da macchina a macchina, senza un senso... Oddio il senso c'era, ma starlo a spiegare in questo contesto non mi pare proprio il caso. Ah bon, possibile. In ogni caso è buona norma cercare di conformare il più possibile il proprio codice ad uno standard portabile, in questo modo compilerà ovunque. I miei progetti Retrogaming Post inviati: 1588 Commento 15 majinga 11 Aprile 2020    13:00:22 Citazione ... int counter1=0, counter2=0, counter3=0; void processo1(void) { wait(); counter1++; printf("Processo1: %6d",counter1); // stampa a video di counter1 attuale signal(); } ... Comunque, quando usi i semafori, è buona norma che il codice sia il più atomico possibile. Dovresti lavorare solo sulle variabili comuni. Tutto il resto dovresti farlo fuori dal semaforo. Commento modificato il 11/04/2020 alle ore 13:00:50 utente amiga quadratico medio Post inviati: 701 Commento 16 AMG_Novice_Usr 11 Aprile 2020    19:48:27 Citazione Quello che l'OP vuole fare è semplicemente un classico esercizio di Sistemi Operativi, comune nello studio della materia. Non ho mai studiato sistemi operativi all'università: ho fatto Elettronica, più che altro HW e fisica dello stesso, di programmazione ho fatto solo un esame di C/C++ molto general purpose, assolutamente nulla di programmazione concorrente, il resto me lo sono raccolto/costruito da solo nel lavoro. Venendo poi da un ambito lavorativo dove si fa più che altro FW "bare metal" dedicato su architetture ARM/Cortex, mi mancano molte cose circa i sistemi operativi … nel tempo libero (poco) sto cercando di colmare qualche lacuna … per cui non sputiamo sopra i semplici esercizi … si inizia da lì. Citazione Comunque, quando usi i semafori, è buona norma che il codice sia il più atomico possibile. Cosa intendi esattamente? Io, nella mia OS-ignoranza, direi così (dimmi se sbaglio): "il codice costituente la wait e la signal deve essere atomico". Anzi, più che atomico … mi azzarderei a dire "ininterrompibile", ossia dentro wait e signal ci devono essere 2 sezioni critiche. Esempio della wait: va evitata la possibilità che il codice compreso fra "l'istante" in cui il processo (o thread) valuta il valore del semaforo e "l'istante" in cui il valore del semaforo viene cambiato (verde -> rosso) dal processo stesso, questo codice appunto non deve essere interrompibile, altrimenti se il reskeduler fa prelazione proprio in quel momento ed assegna la CPU ad un altro processo, anche lui che sta facendo wait su quel semaforo … beh … questo secondo processo potrebbe vedere il semaforo verde, quindi renderlo rosso ed accedere alla risorsa. Se adesso il reskeduler fa prelazione e la CPU ritorna al primo processo, se questo era stato interrotto appena dopo la valutazione del valore del semaforo (il semaforo era verde), allora questo processo non rivaluta il semaforo, quindi non può vedere che nel frattempo è diventato rosso, per cui il processo va spedito per la sua strada, rossifica un semaforo già rosso ed accede alla risorsa … ecco … è avvenuta la perdita di congruenza del dato! (l'ho detta in modo beduino … spero che sia arrivato il messaggio). Citazione Dovresti lavorare solo sulle variabili comuni. Tutto il resto dovresti farlo fuori dal semaforo. Non riesco ad interpretare bene queste 2 frasi. Puoi spiegarmele? Grazie A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 Temibile Pirata Post inviati: 2144 Commento 17 SukkoPera 11 Aprile 2020    19:56:51 Citazione per cui non sputiamo sopra i semplici esercizi … si inizia da lì. E quando l'avrei fatto? I miei progetti Retrogaming utente amiga quadratico medio Post inviati: 701 Commento 18 AMG_Novice_Usr 11 Aprile 2020    20:16:04 Citazione A proposito, esiste anche un porting di GCC per Amiga (che è almeno C99), e una libreria che implementa l'interfaccia POSIX, rendendo quindi possibili praticamente tutte le system call tipiche di Unix. Molto interessante … mi sto documentando sulla faccenda, ma sto trovando difficoltà (la solita barriera di potenziale iniziale … basta qualche lumen dato da chi ha già affrontato la cosa, e l'attraversamento per effetto Tunnel è assicurato! ). In sostanza, è l'analogo per Amiga del progetto Cygwin per Windows … quindi in AmigaOS potrei aprire una shell Korn-like e lavorare come se fossi in un ambiente Unix-like (es: Linux). https://drive.google.com/file/d/1ja6uqTwcIcDsppa2F 4OVuArvqQsB3Qmq/view @SukkoPera Sono andato sul link che hai postato, ho trovato molto materiale, ho dato una letta selettiva al readme: più che altro è interessante dove parla delle differenze fra le systemcall/API dei veri ambienti Unix-like e quelle invece che dovrebbero girare su Amiga, in particolar modo mette in evidenza il comportamento di fork(), diverso su Amiga rispetto a Unix vero, e dice anche il workaround da adottare. Ho visto le cartelle dove sono definite le funzioni standard a noi note … insomma … sembra tutto molto figo e promettente. Ma in pratica non so cosa farci ... Online mi è sembrato di capire che questo materiale vada compilato in qualche modo. Sempre online c'è chi parla del progetto Geek Gadgets / ADE (su Ebay vendono i CD-ROM con tutto il progetto dentro), e parrebbe dal readme del tuo link che prima di passare al materiale del link stesso bisogna installare questo Geek Gadgets. Puoi dire qualcosa in più su tutta questa faccenda? L'obbiettivo è di trasformare un A1200 reale (68EC020, unica espansione è 8MB di fast-ram nella trap-door) in un terminale shell Linux-like. A quel punto vorrei scrivere un programmino main1.c, con un qualunque editor di testo (il programma prevederà sleep, pipe, fork, wait, … il mondo Linux reso disponibile da ixemul.library), dopodiché da riga di comando mi aspetto di poter battere: gcc main1.c -o main1.exe Poi: ./main1.exe Fine della fiera … il programma gira. A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541 Post inviati: 1588 Commento 19 majinga 12 Aprile 2020    12:19:32 Citazione ... "il codice costituente la wait e la signal deve essere atomico". Anzi, più che atomico … mi azzarderei a dire "ininterrompibile", ossia dentro wait e signal ci devono essere 2 sezioni critiche. ... Si, esatto. Il problema che descrivi può succedere con i semafori. Per le funzioni di wait si usano o delle funzioni appositamente ininterrompibili. O si disattivano gli interrupt prima di lavorare sulle variabili. Quindi o usi funzioni atomiche, o ti assicuri che il processo non venga bloccato mentre sta eseguendo la parte relativa al semaforo. Citazione Citazione Dovresti lavorare solo sulle variabili comuni. Tutto il resto dovresti farlo fuori dal semaforo. Non riesco ad interpretare bene queste 2 frasi. Puoi spiegarmele? Grazie E' principalmente una questione di logica di programmazione. Ad esempio nel tuo codice fai una printf mentre stai ancora bloccando il semaforo. Se lo scopo del semaforo fosse di leggere il valore della variabile comune in un dato istante e scriverlo a schermo, potresti anche salvare il valore in una variabile, e poi stamparlo. La printf è una funzione che una volta eseguite fa diverse cose, il processo in quel momento potrebbe essere bloccato, e uno degli altri processi che stanno aspettando che il semaforo si liberi rimarrebbero bloccati in attesa che il valore venga visualizzato a schermo, quando invece potrebbero già accedere alla variabile, visto che il processo non deve più modificarla o non ha più necessità che non venga modificata. In generale, dato che il semaforo è bloccante, e se succede qualcosa al processo che detiene il lock (muore, o va il loop), tutti gli altri processi rimangono bloccati. E sempre buona cosa cercare di minimizzare il codice nel semaforo allo stretto necessario, questo perché più il codice diventa lungo, più è possibile che ci si annidi qualche errore. Quando si usano i semafori va anche modificata un attimo la logica di programmazione, normalmente si ragiona in modo sequenziale, nei semafori si mette al centro la parte concorrente e si scrive l'intorno di conseguenza. Così si ottimizza l'esecuzione dei processi. Commento modificato il 13/04/2020 alle ore 12:14:01 SysAdmin Unix/Linux - fiero o folle possessore di un AmigaOne Post inviati: 3206 Commento 20 VagaPPC 12 Aprile 2020    19:31:09 Per ottenere lo stesso risultato devi ottenere il GCC su Amiga. Con MorphOS è già nativo. Come IDE ti consiglio di imparare VIM, può fare le stesse cose di visual studio, anche senza sbattimenti anche su Amiga puoi ottenere la colorazione del codice. È senza ombra di dubbio il miglior editor, non solo su Amiga, non spaventarti della difficoltà iniziale è ben compensata dalle potenzialità. Ti garantisco che chi lo conosce non può stare senza. Non conosco il C ma programmando in python se importo la classe multithread scrivo allo stesso modo su qualsiasi OS. La stessa cosa vale per il compilatore. Rasberry ha altrettanti parallelismi degli amiga classici, infatti ha 4 core e dei chipset. E linux ha un vero multitasking premtive o per lo meno è compilato come tale per le distro desktop, è possibile compilarlo a bassa latenza per avere un sistema realtime. Quindi non ti preoccupare delle potenzialità. WorkStation: Amiga x5000 AOS4.1 - MorphOS MiniMac - Vampire V4 - PC AMD Ryzen 9 7950X3D 64Gb RAM 5Ghz Old System Amiga 500,1200, A4000/60 PowerPPC, CybervisionPPC, SUN Ultra5, PowerMAC G4 450Mhz 1Gb

Indice: forum / Richieste di Aiuto

Utenti Online

Utenti registrati: 1206 dal 1 Gennaio 2006 di cui online: 3 registrati - cpiace64 - AfAOne - kaffeine - e 52 non registrati Benvenuto all'ultimo utente registrato: zulu Buon Compleanno a kori - galvanica - Maxxx - anemal000 -