Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 11-10-2017, 23:09   #21
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
64KB di RAM? Magari!

Certi microcontroller hanno a malapena 2,5KB di RAM a disposizione, e 32KB di flash per il codice: puoi immaginare i salti mortali necessari per farci stare tutto lì.

Per cui concordo con !fazz. E aggiungo che certe restrizioni che normalmente impongono i s.o. non mi vanno a genio, perché compromettono la creatività del programmatore, e la capacità di risolvere in maniera semplice ed elegante alcune problematiche.

P.S. In ambito embedded non è comune avere a disposizione un'MMU. Per lo meno una PMMU.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 15-10-2017, 15:18   #22
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Il sistema più "sfigato" su cui ho dovuto lavorare era VxWorks con CPU Motorola 68'000 e 32 MB di RAM! Praticamente un Amiga, ma molto meno divertente
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 15-10-2017, 17:54   #23
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Il mio Amiga 2000 aveva un 68000 (a 7Mhz) e 1MB di RAM: praticamente il tuo VxWork era un mostro di sistema.

Ma 32MB francamente non mi tornano, visto che il 68000 aveva 16MB di spazio d'indirizzamento totale (estendibile a 64MB utilizzando i famigerati function code. Fattibile, ma solo sulla carta, visto che il 68000 non aveva istruzioni di spostamento dati fra diversi spazi d'indirizzamento coi function code: serviva almeno un 68010 allo scopo).

Quindi immagino che tu abbia avuto almeno un 68020 per gestire tutta quella memoria (ci sarebbe anche il 68012, che è un 68010 con supporto a 1GB di address space, ma è molto raro e ha avuto poca fortuna), che era tutt'altra cosa.

Comunque credimi: ci sono SoC embedded talmente limitati con le risorse (ma nonostante tutto molto diffusi) che un sistema come il tuo sembra fantascienza.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 16-10-2017, 13:07   #24
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Il mio Amiga 2000 aveva un 68000 (a 7Mhz) e 1MB di RAM: praticamente il tuo VxWork era un mostro di sistema.

Ma 32MB francamente non mi tornano, visto che il 68000 aveva 16MB di spazio d'indirizzamento totale (estendibile a 64MB utilizzando i famigerati function code. Fattibile, ma solo sulla carta, visto che il 68000 non aveva istruzioni di spostamento dati fra diversi spazi d'indirizzamento coi function code: serviva almeno un 68010 allo scopo).

Quindi immagino che tu abbia avuto almeno un 68020 per gestire tutta quella memoria (ci sarebbe anche il 68012, che è un 68010 con supporto a 1GB di address space, ma è molto raro e ha avuto poca fortuna), che era tutt'altra cosa.
Non ricordo di preciso quale 68K fosse, ma ricordo che all'inizio avevano 16 MB, ma poi dovettero portarli a 32 MB non so quale "trusco" usarono per farlo... era una versione di VxWorks "pasticciata" visto che il cliente ce l'aveva così mastodontico che aveva pure i sorgenti del kernel / libc... alcuni driver se li avevano scritti loro con risultati beh ridicoli
(Tipo che la seriale era più veloce della rete!)

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Comunque credimi: ci sono SoC embedded talmente limitati con le risorse (ma nonostante tutto molto diffusi) che un sistema come il tuo sembra fantascienza.
Sì noi chiamiamo "embedded" cose che non lo sono propriamente... comunque talvolta è imbarazzante e poco giustificabile vedere praticamente lo stesso software arrancare su un Atom con 1 GB di RAM... c'è qualcosa di sbagliato non so in X86 o in Linux ma è indubbiamente più pesante il tutto
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 16-10-2017, 17:03   #25
!fazz
Moderatore
 
L'Avatar di !fazz
 
Iscritto dal: Nov 2006
Messaggi: 20777
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
64KB di RAM? Magari!

Certi microcontroller hanno a malapena 2,5KB di RAM a disposizione, e 32KB di flash per il codice: puoi immaginare i salti mortali necessari per farci stare tutto lì.

Per cui concordo con !fazz. E aggiungo che certe restrizioni che normalmente impongono i s.o. non mi vanno a genio, perché compromettono la creatività del programmatore, e la capacità di risolvere in maniera semplice ed elegante alcune problematiche.

P.S. In ambito embedded non è comune avere a disposizione un'MMU. Per lo meno una PMMU.
ho per le mani ancora qualcosa di più assurdo, giusto oggi sto mettendo le mani su un progetto basato su un PIC12LF1552 con 2048 word di flash e ben 256 byte di ram vi lascio immaginare i numeri da circo xd
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX)
Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000

Ultima modifica di !fazz : 16-10-2017 alle 17:06.
!fazz è offline   Rispondi citando il messaggio o parte di esso
Old 17-10-2017, 07:00   #26
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da fano Guarda i messaggi
Non ricordo di preciso quale 68K fosse, ma ricordo che all'inizio avevano 16 MB, ma poi dovettero portarli a 32 MB non so quale "trusco" usarono per farlo... era una versione di VxWorks "pasticciata" visto che il cliente ce l'aveva così mastodontico che aveva pure i sorgenti del kernel / libc... alcuni driver se li avevano scritti loro con risultati beh ridicoli
(Tipo che la seriale era più veloce della rete!)
Sono ragionevolmente sicuro che si trattasse di almeno un 68020. E ti assicuro: è tanta roba. Così comodo, che potrei svilupparci in assembly anche dei progetti anche di una certa dimensione. Nulla a che vedere con schifezze come PIC et similia: l'assembly 680x0 rimane "da urlo" ancora oggi.
Quote:
Sì noi chiamiamo "embedded" cose che non lo sono propriamente... comunque talvolta è imbarazzante e poco giustificabile vedere praticamente lo stesso software arrancare su un Atom con 1 GB di RAM... c'è qualcosa di sbagliato non so in X86 o in Linux ma è indubbiamente più pesante il tutto
Non credo sia x86 il problema. x86, specialmente in versione 16 bit, è una delle ISA più compatte nonché parca di risorse. Ma anche la versione a 32 bit (80386+) produce codice con una buona densità.

Il problema è... quello che ci devi fare. Ovviamente più il software da sviluppare è complesso, e più risorse richiederà.
Quote:
Originariamente inviato da !fazz Guarda i messaggi
ho per le mani ancora qualcosa di più assurdo, giusto oggi sto mettendo le mani su un progetto basato su un PIC12LF1552 con 2048 word di flash e ben 256 byte di ram vi lascio immaginare i numeri da circo xd
Ma LOL Perfino il Commodore Vic 20 era messo meglio.

In tutta onestà non t'invidio. Con quelle poche risorse molto probabilmente sarai costretto a scrivere codice in assembly. E l'assembly dei PIC è a dir poco rivoltante. Talmente rivoltante che una ventina d'anni fa mi scrissi un assembler di più alto livello, pur di non usare quello standard di Microchip.

Fosse per me, 68020+ tutta la vita. Seconda scelta: 80386.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 17-10-2017, 11:02   #27
!fazz
Moderatore
 
L'Avatar di !fazz
 
Iscritto dal: Nov 2006
Messaggi: 20777
per me una delle microarchietture migliori, una volta capita, è la cortex m4 e la cosa assurda è che è stata rifiutata in quel progetto perchè il micro era troppo costoso (si parla di circa 3€ di differenza su una macchina da minimo 20k€ )

l'm4 ma in generale quasi tutte le archiettture arm based hanno una flessibilità in termini di periferiche e piedinature che semplificano il routing in maniera imbarazzante
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX)
Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000
!fazz è offline   Rispondi citando il messaggio o parte di esso
Old 18-10-2017, 06:25   #28
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da !fazz Guarda i messaggi
per me una delle microarchietture migliori, una volta capita, è la cortex m4 e la cosa assurda è che è stata rifiutata in quel progetto perchè il micro era troppo costoso (si parla di circa 3€ di differenza su una macchina da minimo 20k€ )
Dipende quanti pezzi ne vendono di quelle macchine.

Fino all'ordine di qualche centinaio ha senso poter usare un microcontroller migliore come l'M4, vista la differenza irrisoria e considerato che potrebbe richiedere meno tempo di sviluppo al programmatore.

Ma già arrivando all'ordine delle migliaia la differenza si fa sensibile, e puoi arrivarci a coprire il costo di un dipendente.

Ricominciando a lavorare un po' in area embedded si capisce il perché si facciano delle scelte che a noi sviluppatori sembrano insensate.
Ad esempio l'adozione di economiche memorie eMMC anziché SSD capaci di maggiori cicli di scrittura nella centralina delle automobili: all'azienda è più conveniente pagare uno sviluppatore per un anno intero a ottimizzare le scritture su eMMC, anziché spendere qualche euro in più per un miglior SSD. Anche un solo euro per 3 milioni di auto l'anno fanno 3 milioni euro (l'anno, appunto), mentre lo sviluppatore costa più di un ordine di grandezza di meno e per un solo anno.

Quindi niente: chi lavora nell'embedded è destinato a soffrire, usando poche risorse da rivoltare come un calzino.
Quote:
l'm4 ma in generale quasi tutte le archiettture arm based hanno una flessibilità in termini di periferiche e piedinature che semplificano il routing in maniera imbarazzante
Infatti da questo punto di vista non ho nulla da dire. D'altra parte è proprio il dominio di ARM.

Prima riguardo a 68K e 386 parlavo esclusivamente come programmatore: mi trovo più a mio agio a scrivere codice assembly con queste architetture, che con ARM (Thumb 2 nel caso dell'M4).
Quote:
Originariamente inviato da Antonio23 Guarda i messaggi
Armv7-M, l'M4 e' il nome del micro.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 18-10-2017, 19:52   #29
!fazz
Moderatore
 
L'Avatar di !fazz
 
Iscritto dal: Nov 2006
Messaggi: 20777
l'ordine è delle migliaia di macchine (non è di certo al livello dei numeri dell'automotive ) il settore è lo stesso ma dall'altra parte della sponda sono macchine da utilizzare nelle linee di assemblaggio di cui un 20% con software customizzato ergo .....

@Antonio23 se proprio vogliamo fare i pignoli arm7E-M è il nome dell'architettura , cortex M4 è il nome del core mentre il nome del micro ERA STM32F4[qualcosa]
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX)
Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000

Ultima modifica di !fazz : 18-10-2017 alle 19:56.
!fazz è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
SU7, la super auto elettrica di Xiaomi p...
Il Mac Mini 2023 con chip M2 8/256 GB è ...
Questo Mini PC ha un super prezzo: diffi...
Il doppio gioco di Twitter: battaglie le...
Top 7 Amazon per risparmiare tantissimo:...
Apple premia 350 studenti ''maghi'' prog...
Apple Store: con questa macchina si poss...
iPad Pro 2024 arriveranno a maggio. Paro...
JBL Soundgear Sense: contatto costante c...
Prezzo bomba: il super tablet 10.1"...
Google torna sui suoi passi: Pixel 8 ric...
TOP! Display gaming 27" 2560x1440 p...
FuryGPU: un appassionato ha creato da ze...
Regno Unito, rischio apocalisse IA: mili...
Creato un transistor che può esse...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 10:19.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www3v