Spin-Compiler überall... auch auf PI und Co...

Allgemeine Themen rund um den Propeller Mikrocontroller und Elektronik
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Spin-Compiler überall... auch auf PI und Co...

Beitrag von yeti »

----------8<-----{20170507-1030-GMT}----->8----------

Es wird langsam kritisch für 64bit-Linuxer...

Code: Alles auswählen

yeti@kumari:16)~/wrk/propeller/bst$ ls -l
insgesamt 7492
-rwxr-xr-x 1 yeti yeti 3167888 Mär 10  2010 bst-0.19.3
-rwxr-xr-x 1 yeti yeti 3196704 Apr 20  2010 bst-0.19.4-pre9
lrwxrwxrwx 1 yeti yeti      11 Feb 21  2014 bstc -> bstc-0.15.3
-rwxr-xr-x 1 yeti yeti  143652 Jul 20  2009 bstc-0.15.3
-rwxr-xr-x 1 yeti yeti  149412 Apr 21  2010 bstc-0.15.4-pre9
-rwxr-xr-x 1 yeti yeti  103676 Jul  3  2009 bstl-0.05
-rwxr-xr-x 1 yeti yeti   45752 Apr 28  2010 bstl-0.07-pre1
-rw-r--r-- 1 yeti yeti  713242 Aug  7  2010 bst_manual_0.04.pdf
-rwxr-xr-x 1 yeti yeti  128660 Jan 21  2012 PropBasic-bst-00.01.14-79
(yeti@kumari:16)~/wrk/propeller/bst$ ./bst-0.19.3
bash: ./bst-0.19.3: Datei oder Verzeichnis nicht gefunden
(yeti@kumari:16)~/wrk/propeller/bst$ ./bst-0.19.4-pre9 
bash: ./bst-0.19.4-pre9: Datei oder Verzeichnis nicht gefunden
(yeti@kumari:16)~/wrk/propeller/bst$ file bst-*
bst-0.19.3:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
bst-0.19.4-pre9: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
(yeti@kumari:16)~/wrk/propeller/bst$ ldd bst-*
bst-0.19.3:
        das Programm ist nicht dynamisch gelinkt
bst-0.19.4-pre9:
        das Programm ist nicht dynamisch gelinkt
(yeti@kumari:16)~/wrk/propeller/bst$ ./bstc-0.15.3 |& head -2
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
(yeti@kumari:16)~/wrk/propeller/bst$ _
BSTC ist auch ein 32bit-Programm, aber es benötigt nicht viel, um heute noch auf 64bittigen Systemen zu laufen.
BST braucht quasi einen kompletten Satz Bibliotheken eines 32bittigen X11s zusätzlich zum eh Installierten 64-Bit-X11 und noch etwas mehr Verwaltungskram drumrum.
Das mag nicht jeder seinem sauberen 64bit-System antun...

BST scheidet also für manchen heute schon aus und in kommenden neuen Versionen unsererer Pinguin-OSe wird sich an den Bibliotheken irgendwann soviel geändert haben, daß auch mit 32bit-Kompatibilitätspaketen (die dann ja die aktuellen Libs in 32bittiger Version enthalten werden) auch nix mehr reißen läßt. Allerspätestens wenn uns dann die Umstellung von X11 auf Wayland trifft wird Schluß sein mit BST. Und diese Umstellung wird dann auch BST auf 32bittigen Linuxen abschießen.

Sollen wir dann Windows installieren um weiter mit dem Hive zu spielen?
Vielleicht täte es auch eine dann museumsreife Linux-Distribution in einer virtuellen Maschine... ok...

Dies Problem hat mich gestern in den Hintern gebissen, denn frische TriOS-Quellen erfordern ja das Entfernen eines Lattenzaunes vor einer der TV- oder VGA-Defines.

Nach Fehlversuchen mit anderen Editoren stellte sich heraus, daß EMACS Files in diesem schrulligen Parallax-schen Format...

Code: Alles auswählen

$ file flash/bellatrix/belflash.spin 
flash/bellatrix/belflash.spin: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators
...zu beherrschen scheint. Das Ergebnis war jedenfalls kompilierbar...

Code: Alles auswählen

$ ls -l bin/flash/
insgesamt 56
-rw-r--r-- 1 yeti yeti 14356 Mai  6 19:02 admflash.binary
-rw-r--r-- 1 yeti yeti  7624 Mai  6 19:02 belflash.binary
-rw-r--r-- 1 yeti yeti 32584 Mai  6 19:02 regflash.binary
Also kurz- oder mittelfristig kann ich noch mitspielen... den Rest sollt man mal in Ruhe ausdiskutieren und vielleicht die Entwicklung von OpenSpin in die Richtung stubsen, die wir für TriOS brauchen...

----------8<-----{20170507-1450-GMT}----->8----------

Ok... das wird jetzt etwas schräg, könnte aber eine Perspektive werden:
 <br /> <br />Nicht heute, aber vielleicht in Zukunft ein Plan-B...<br /> 
 
 
Nicht heute, aber vielleicht in Zukunft ein Plan-B...
 
Untertitel: Wenn schon schräg, dann richtig! :-P

...aber (mit z.B. VM-Klimmzügen) langfristig bei BST bleiben scheint mir noch immer ein arg gruseliger Gedanke...

----------8<-----{20170507-1632-GMT}----->8----------

...natürlich könnt man auch ein Linux-basiertes 32bittiges OS in einer VM rennen lassen, aber wenn die Libs oder Wayland einen Einsatz von BST auf aktuellen Distributionen verhindern ist vielleicht ein aktuelles ReactOS fahren besser als ein veraltetes Pinguinchen...

Vollständigkeitshalber ein passender Schnappschuß:
 <br /> <br />Devuan1 auf Debian8... ;-)<br /> 
 
 
Devuan1 auf Debian8... ;-)
 
... im Gegensatz zu ReactOS oder Windows in einer VM hat dies für den langjährigen Pinguinzüchter natürlich den Charakter eines Heimspieles...

Wie lang mag BST noch auf Windowsversionen laufen?
Gibt es da irgendwelche dunklen Wolken am Horizont?
App-Shop-Modell?
...bald nur noch MS-abgesegnete signierte Binaries auf Windows?

----------8<-----{OmmmMMMmmmPtimistisch bleiben...}----->8----------
Zuletzt geändert von yeti am Fr 19. Mai 2017, 16:13, insgesamt 2-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
PIC18F2550
Beiträge: 2831
Registriert: Fr 30. Sep 2011, 13:08

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von PIC18F2550 »

Yeti Du malst das alles wieder in den schönsten, grössten, buntesten schwarzen Wolken.

Kann man das BST nicht in eine kleine live Version für die Ewigkeit (unter der Voraussetzung noch vorhandener und Funktionstüchtiger Hartware) versenken?
Gruß
PIC18F2550

drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.
ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

PIC18F2550 hat geschrieben:Yeti Du malst das alles wieder in den schönsten, grössten, buntesten schwarzen Wolken.
...mein Schwarz ist am Buntesten!!!
Ich hab das auch laaaaaaange geübt!
PIC18F2550 hat geschrieben:Kann man das BST nicht in eine kleine live Version für die Ewigkeit (unter der Voraussetzung noch vorhandener und Funktionstüchtiger Hartware) versenken?
Notlösungen gibt es viele... aber warum soll ich mich von der Software von jemandem der nichtmal in der Lage war Backups zu machen dazu zwingen lassen, nicht mit meinem Lieblings-OS auf meinem Lieblingsgerät zu arbeiten?

BST war nur binär frei... und das ist mir eigentlch aus Prinzip eh schon zuwenig... erst recht, wo es heute OpenSpin gibt...

Hat des BST-Autors Quelltexte-Verlieren denn nicht zur Genüge bewiesen, daß nicht quelloffene Software Mist ist?
Hätte er den Quelltext verteilt, wäre sein Plattencrash nicht das Ende von BST geworden...

Ich krieg 'n Adrenalintsunami, wenn ich daran denke...

Eine Live-Version hat gegenüber einer VM einen einfacheren Zugriff auf die Hardware. Das Schubsen der Kompilate in den Propeller könnte dadurch etwas einfacher sein als per VM-Umweg...

...aber andersrum wird damit auch nur ein kleiner Prozentsatz der Anwender zufrieden sein, denn jeder will dann eine Liveversion des Linuxes, das er am Besten kennt und 20 verschiedene Live-CDs kann/will keiner auf Dauer pflegen... und mit eingefrorenem BST ist da ja auch nicht Schluß, denn die Benutzer wollen ihre aktuellen Lieblingstools haben, egal ob sie zur eingefrorenen Alt-Distribution passen...

...und was soll Roy sagen?
Da hat er Jaaaahre seines Lebens an OpenSpin gesessen und das spektakulärste Spin-Projekt der Welt ignoriert OpenSpin und klebt an BST(C)...

Ist das unfair oder ist das unfair?

Wir müssen ja nicht morgen umgestiegen sein, aber wenigstens mal eine Aussage, daß dies längerfristig doch eine gute Idee sein könnte, wäre schon ein Zeichen und würde mich massiv beruhigen...
Zuletzt geändert von yeti am So 14. Mai 2017, 20:16, insgesamt 1-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

----------8<-----{20170514-1706-GMT}----->8----------

Zombies, wollt ihr ewig sterben?

Heute schon gegruselt?

Hat die NRW-Wahl echt noch nicht gereicht?

Na dann... ich hab euch gewarnt!!!

Code: Alles auswählen

(yeti@cubietruck0:9)/opt/bst/bin$ cat /etc/debian_version 
7.11
(yeti@cubietruck0:9)/opt/bst/bin$ uname -a
Linux cubietruck0 3.4.79 #1 SMP PREEMPT Sat Nov 22 09:37:52 CST 2014 armv7l GNU/Linux
(yeti@cubietruck0:9)/opt/bst/bin$ qemu-i386 bstc -v
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
...irgendwie kann man dem Kernel auch sagen, daß er die i386-Binärchen selber erkennen soll (Stichwort "binfmt_misc")... aber in der Konfiguration dieses Features verlaufe ich mich grad noch. Vielleicht zickt auch nur dies Cubieez/Wheezy... oder 's braucht 'n Reboot, damit das Alles nach Installation aktiv wird... ich hab 'n paar dauerlaufen-sollende Services auf diesem Cubienchen... mag also grad nicht rebooten... ich probier's irgendwann aber auch mal aufm RasPI... weil's sooooo schön gruselt... mwhuaaahahahahahaaaaa...

----------8<-----{20170514-1825-GMT}----->8----------

Bis ich mehr rausfinde, muß der Aufruf mit vorangestelltem "qemu-i386" genügen:

Code: Alles auswählen

(yeti@cubietruck0:3)/tmp$ cat huhu.spin 
con
  _clkmode = xtal1|pll16x
  _clkfreq = 80_000_000
 
obj
  ser : "FullDuplexSerial"
 
pub main
  ser.start(31, 30, 0, 115200)
  ser.str(string("Huhu, OpenSpin!",13,10))
  waitcnt(_clkfreq + cnt)
  ser.stop
(yeti@cubietruck0:3)/tmp$ qemu-i386 /opt/bst/bin/bstc -b -Oa -L /opt/parallax.spin.src/spin huhu.spin  
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object huhu
Loading Object FullDuplexSerial
Program size is 568 longs
Compiled 182 Lines of Code in 1.073 Seconds
(yeti@cubietruck0:3)/tmp$ /opt/spinsim/bin/spinsim -b huhu.binary 
Huhu, OpenSpin!

(yeti@cubietruck0:3)/tmp$ ls -l huhu.*
-rw-r--r-- 1 yeti yeti 572 Mai 14 18:18 huhu.binary
-rw-r--r-- 1 yeti yeti 207 Mai 14 18:15 huhu.spin
...ok... nächstes Mal denk ich auch dran, das Testprogrämmli "Huhu, BSTC!" ausgeben zu lassen... aber nimmer jetzt...

----------8<-----{20170514-2024-GMT}----->8----------

Da brat mir doch einer 'n Storch!

Code: Alles auswählen

(yeti@cubietruck0:3)~$ file ./Sync/openspin-linux-amd64  
./Sync/openspin-linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=0x765690cb1416e3d30c4f24bc459b9b9f82aaf30e, stripped
(yeti@cubietruck0:3)~$ ./Sync/openspin-linux-amd64 2>/dev/null
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2016 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.80 Compiled on May  8 2017 04:19:27
...warum ich bei i386-Binärchen "qemu-i386" explizit angeben muß, aber die Cubiene Debian-x86_64-Binärchen transparent erkennt und selber den richigen Qemu-Vorsatz einspannt, kappier ich derzeit nicht. Aber zumindest zeigt's an diesem Amd64-OpenSpin, daß es prinipiell geht...

----------8<-----{20170514-2039-GMT}----->8----------

Herr Ober! Noch'n Storch!!!

Code: Alles auswählen

(yeti@cubietruck0:3)~/Sync$ file openspin 
openspin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=0xeadae60d8421e98dd858823e8c6e7729b7ddaaa2, stripped
(yeti@cubietruck0:3)~/Sync$ ./openspin 2>/dev/null
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2016 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.80 Compiled on Jun  6 2016 12:42:51
...es klappt also jetzt schon transparent für "neuere" 32bit-x86-Binärchen. Das Uralt-BSTC hat vermutlich einen anderen Magic-Header und wird daher nicht von den Binfmt-Funktionen erkannt... ich werd darüber noch etwas mehr lesen müssen bis es dann endlich auch mit BSTC ohne qemu-i386 davor klappt.

----------8<-----{20170514-2117-GMT}----->8----------

Ooooobeeeeerrr! Und jetzt 'n Nandu!

Code: Alles auswählen

(yeti@cubietruck0:3)/tmp$ cat xyzzy
#!/bin/sh
echo ':bstc-i386:M::\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff:/usr/bin/qemu-i386:' > /proc/sys/fs/binfmt_misc/register
(yeti@cubietruck0:3)/tmp$ sudo ./xyzzy
...jetzt haben wir eine spezielle Lex-BSTC in den Binfmt-Regeln:

Code: Alles auswählen

(yeti@cubietruck0:3)/tmp$ cat /proc/sys/fs/binfmt_misc/bstc-i386 
enabled
interpreter /usr/bin/qemu-i386
flags: 
offset 0
magic 7f454c46010101030000000000000000020003
mask ffffffffffffffffffffffffffffffffffffff
...und siehe da: Nun klappt's auch ohne "qemu-i386" davor tippen:

Code: Alles auswählen

(yeti@cubietruck0:3)/tmp$ /opt/bst/bin/bstc -v
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Das automatische Installieren dieser Lex-BSTC nach Reboot werd ich demnächst mal untersuchen...

----------8<-----{20170514-2236-GMT}----->8----------

Nich daß das jetzt wer in den phallisch phöllschen Hals bekommt: Ich halte BST(C) noch immer für hochgradig vermeidenswert... aber mit binfmt_misc und dem ganzen Jedöns drumrum wollte ich mich schon lange mal beschäftigen und irgendwie haben die Teile plötzlich auf eine Art und Weise ineinander gepaßt, die nun leider zu Gunsten von BSTC ausgeht: Statt schneller seiner von mir so ersehnten Obsoleszenz anheim zu fallen hat es jetzt sogar noch eine Zukunft auf Systemen bekommen, für die dieser Qemu-Hack greift... :-(

Shit happens!

Verdammt!

----------8<-----{Schulz! Ente! Aus!}----->8----------
Zuletzt geändert von yeti am Mi 17. Mai 2017, 17:05, insgesamt 1-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

----------8<-----{20170517-0330-GMT}----->8----------

Jetzt der Test auf Raspbian-Jessie-Lite...

Code: Alles auswählen

(yeti@pi2-0:1)~$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Zusätzlich installiert (epische Ausgaben nicht mit kopiert):

Code: Alles auswählen

(yeti@pi2-0:1)~$ sudo apt-get install binfmt-support qemu-user unzip wget
BSTC besorgen:

Code: Alles auswählen

(yeti@pi2-0:1)~$ wget http://www.fnarfbargle.com/bst/bstc/Latest/bstc-0.15.3.linux.zip
--2017-05-17 05:16:25--  http://www.fnarfbargle.com/bst/bstc/Latest/bstc-0.15.3.linux.zip
Auflösen des Hostnamen »www.fnarfbargle.com (www.fnarfbargle.com)«... 93.93.131.67
Verbindungsaufbau zu www.fnarfbargle.com (www.fnarfbargle.com)|93.93.131.67|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 142221 (139K) [application/zip]
In »»bstc-0.15.3.linux.zip«« speichern.

bstc-0.15.3.linux.zip     100%[=====================================>] 138,89K   814KB/s   in 0,2s   

2017-05-17 05:16:25 (814 KB/s) - »»bstc-0.15.3.linux.zip«« gespeichert [142221/142221]

(yeti@pi2-0:1)~$ unzip bstc-0.15.3.linux.zip 
Archive:  bstc-0.15.3.linux.zip
  inflating: bstc.linux
Erster Test:

Code: Alles auswählen

(yeti@pi2-0:1)~$ qemu-i386 bstc.linux -v
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Binfmt das Erkennen von BSTC beibringen und reboot...

Code: Alles auswählen

(yeti@pi2-0:1)~$ echo ':bstc-i386:M::\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03::/usr/bin/qemu-i386:' | sudo tee /etc/binfmt.d/bstc-i386.conf 
:bstc-i386:M::\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03::/usr/bin/qemu-i386:
(yeti@pi2-0:1)~$ sudo reboot
Zweiter Test:

Code: Alles auswählen

(yeti@pi2-0:1)~$ ./bstc.linux -v
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
...nun klappt's auch ohne qemu-i386 davor... ;-)

----------8<-----{Schulz! Ente! Aus!}----->8----------
Zuletzt geändert von yeti am Mi 17. Mai 2017, 12:22, insgesamt 1-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

----------8<-----{20170517-0752-GMT}----->8----------

Freigehalten für z.B. Devuan1...

Da klapp's grad irgendwie nicht mit der Konfiguration durch Konfigschnipsel in /etc/binfmt.d und wenn ich sehe, wie das in Devuan geregelt wird, wird's dazu auch ein paar Zeilen geben.

Vermutlich wird dann auch klar, wie das in SystemD-freien Debian-Variationen zu erledigen ist, also rückwirkend auch für das Wheezy aufm Cubienchen.

Ok... /etc/binfmt.d scheint in Raspbian/Jessie von SystemD gemanagt zu werden. Für SystemD-freie Pinguine sehe ich grad noch nicht, was da der einfachste Weg wird... eine "update-binfmts und-ein-paar-Optionen"-Zeile zu /etc/rc.local hinzufügen scheint mir grad der minimalinvasive Weg zu sein... aber ein Initskript, um selber /etc/binfmt.d zu managen wäre vielleicht auf Dauer besserer... das Thema braucht scheinbar noch mehr OmmmmMMMmmmMMMMmmmmm....

----------8<-----{Schulz! Ente! Aus!}----->8----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

----------8<-----{20170517-1803-GMT}----->8----------

Alle lieben Benchmarks!

Aufgabe: TriOS-R57 bauen.

Code: Alles auswählen

Zeit     Gerät           RAM   OS
======================================================
--<bstc qemuliert>------------------------------------
 4m31s   PI3-B         1024M   Raspbian/Jessie(-Pixel)
 7m30s   Cubietruck    2048M   Cubieez/Wheezy
 7m31s   PI2-B         1024M   Raspbian/Jessie(-Lite)
 8m13s   PI3-B         1024M   Devuan/Jessie-64bit
23m18s   PI1-B+         512M   Raspbian/Jessie(-Pixel)
--<bstc nativ>----------------------------------------
-todo-   T23@1133Mhz    512M   Debian/Jessie-32bit
 0m22s   T30@2GHz      1024M   Debian/Jessie-32bit
-todo-   T60@1.66GHz   2048M   Debian/Jessie-64bit
 0m05s   T510@2.4GHz   8192M   Debian/Jessie-64bit
======================================================
Ich denke, der fetteste Applaus gehört dem PI1-B+!
Volle 1000 Sympathiepunkte! \o/

Derzeit wird vom Buildskript nur eine CPU in Schweiß gehalten, also könnten Optimierungen theoretisch auf dem Cubietruck rund Faktor 2 rausholen und auf dem PI2/PI3 könnte bis zu Faktor 4 drin sein.

Problem: Ein ordentliches Makefile für Spin-Projekte basteln ist gruselig. Man müsste den Spin-Compiler laufen lassen, um die Abhängigkeiten zu erkennen (oder noch gruseliger und fehleranfälliger: die Abhängigkeiten im Makefile selber aktuell halten), um dann daraus das Makefile zu generieren. Das alleine dauert vermutlich schon fast so lange, wie einfach brutal rücksichtslos Alles neu zu bauen.

Drollig: Der 64bittige ARMische Quadcore mit 1200Mhz (PI3) ist langsamer als der 32bittige ARMische Quadcore mit 900MHz (PI2). 64bit sind nicht immer von Vorteil! Vermutlich wäre der PI3 mit einem 32bit-OS dann doch schneller. Vielleicht teste ich mal die PI2-Devuan/Jessie-Variante auf dem PI3... irgendwann... nicht jetzt...

----------8<-----{20170519-2252-GMT}----->8----------

Ich hab den Zeitbedarf des TriOS-Bauens auf PI3 unter Raspbian-Jessie-Pixel mehrfach laufen lassen mit unterschiedlichen Netzteilen und USB-Kabeln und bekam dabei Zeiten von 4m31s bis 7m30s...

Waliüm datt denn?

Je nach beim PI ankommender Spannung oder besser gesagt Unterspannung schaltet er mehr oder weniger oft in den Schongang... das ist keine neue Erkenntnis, aber ich habe sie für die anderen PI-Benchmarks nicht berücksichtigt. Die werde ich also nach und nach mal mit besserer Bestrohmsung neu machen dürfen...

+++edit@20170520-0026-GMT
...oder auch nicht... keine Strafarbeit, kein Nachsitzen, kein Neurennen aller Benchmarks: Der Undervoltage-Schongang scheint überwiegend ein PI3-Problem zu sein. Beim PI2 sah ich den gelben Blitz jedenfalls kein mal beim TriOS-Bauen mit gleichzeitigem Warpaint-Videos laufen lassen...
---edit@20170520-0026-GMT


----------8<-----{Schulz! Ente! Aus!}----->8----------
Zuletzt geändert von yeti am Di 23. Mai 2017, 17:18, insgesamt 3-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
BorgKönig
Beiträge: 598
Registriert: So 24. Mai 2009, 11:24

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von BorgKönig »

ich hab den faden mal neu gelegt ;) @yeti: passt das hier besser für dich?
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von yeti »

BorgKönig hat geschrieben:ich hab den faden mal neu gelegt ;) @yeti: passt das hier besser für dich?
Jo... ich denk, hier paßt's besser...
Die Grundsazufrage am Anfang des Threads, ob wir nicht doch besser mal von BST(C) wegkommen sollten, hatte zwar gut in "Fragen, Anregungen und Kritik" gepaßt, aber der weitere Verlauf wurde dann doch eher ein Selbsthilfeleitfaden in Software... ;-)
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
TuxFan
Beiträge: 1022
Registriert: So 6. Sep 2009, 11:18

Re: Es wird langsam kritisch für 64bit-Linuxer...

Beitrag von TuxFan »

Moin moin!
BorgKönig hat geschrieben:ich hab den faden mal neu gelegt ;) ...........
"Voll verschoben" ....... woran erinnert mich das jetzt? :roll: Die kleinen Gelben kommen ja auch wieder ins Kino... :DAUMENHOCH ................ ääääääääääääääääähhhhhhhhhhhhh ............lassen wir das jetzt mal beiseite, hilft leider bei OpenSpin, PropellerIDE und BST-Problematik nicht weiter.
Was mach ich mit dem Dilemma ?
Im Gegensatz zu Yeti verfolge ich eher das Zusammenspiel von IDE und Compiler, da ich dies aus meiner Programmiertätigkeit mit Fortran so gewöhnt bin.
PropellerIDE und OpenSpin sind eigentlich soweit, daß man damit arbeiten kann. Läuft zwar nicht alles optimal rund aber Einiges im Bereich der einpropellerigen Maschinen lässt sich damit schon bewerkstelligen. Also für meine Eigenbrödeleien wirds wohl reichen. ;)
Bei Augenmerk auf Trios, werd ich mal bei Gelegenheit die einzelnen Teilstücke, wie letztens bei belflash, mit OpenSpin compilieren und am lebenden Objekt Hive ausprobieren. Gegebenenfalls muß man mal an dieser und jener Stelle die Feile, Säge oder Kleber ansetzen, um zum Ziel zu gelangen, ist ja open source. Dazu mal bei GITte Parallax eventuelle Wünsche äußern um PropellerIDE und/oder OpenSpin zu optimieren, falls die Verantwortlichen dazu bereit sind.
Ich versuch dann mal Laut zu geben wie es im einzelnen läuft.

Kommt Zeit kommt Unkraut.........
Gruß
TuxFan
Wunder gibt es immer wieder.......
Antworten