Ernstzunehmende Programme in BASCOM

Ob ein Programm "ernsthaft" ist oder nicht, macht sich nicht an der 
Programmiersprache fest. Nur weil eine bestimmte IDE es erlaubt, 
unübersichtlich und liederlich zu progrsammieren, muss man das ja nicht 
so machen.

Ein guter Programmierer hat sicher seine persönliche Lieblingssprache 
oder gewisse Zwänge (z.B. verfügbare Bibliotheken, Teamarbeit) bedingen 
eine konkrete Programmierumgebung - d.h. aber nicht, dass alles andere 
automatisch Mist ist.

Normalerweise antworte ich nicht auf solche Fragen von einem (Gast),
weil es oft genug nach Stunksuche aussieht. Trotzdem: Hier ein Link
zur Codesammlung von MCS-Electronic (Hersteller von Bascom). Dort
kannst Du auch ziemlich umfangreiche und anspruchsvolle Aufgaben-
lösungen finden:

http://www.mcselec.com/index.php?option=com_content&task=category&sectionid=7&id=79&Itemid=57

Es gibt Leute, die haben ein Problem zu loesen, und verwenden nun 
Bascom. Moeglicherweise weils schneller geht.

Bascomnutzer schrieb:
> Für richtig Zeitkritische Anwendungen (RT) sehe ich Bascom eher als
> schwierig an.

Daß Inline-Assembler möglich ist, ist Dir nicht bekannt?

(Gast) schrieb:
> Gibt es hier jemanden der ernstzunehmende Programme in BASCOM schreibt?

Ist dir der Vektor-Antennen-Analyzer FA-VA3 von DL1SNG „ernsthaft“
genug?

Es gibt Leute (C), die schwatzen viel von Portierbarkeit. Andere wollen 
nur ein Problem geloest haben und nachher vergessen.
Ja, es gibt auch Loesungen, die man portieren moechte. Sofern das denn 
ueberhaupt geht.

Jetzt Nicht schrieb:
> Andere wollen nur ein Problem geloest haben und nachher vergessen.

Das ist kein Grund, denen, die in C programmieren, zu unterstellen,
dass sie etwas anderes möchten.  Auch die wollen ihr Problem gelöst
haben und es danach vergessen.  Wenn man die Sprache kennt und sich
über die Zeit seine eigenen Codeschnipselchen oder Bibliotheken
gezimmert hat und/oder auf solche aus dem Netz zurückgreifen kann,
ist das absolut kein Problem.

Aber es ist eben auch überhaupt keine Frage, dass man deshalb nun
mit einem Tool wie Bascom irgendwie schlechter arbeiten müsste als
jemand, der all seinen Kram in C macht.  Bascom hat neben der anderen
Programmiersprache einfach einen anderen Anspruch und verhilft damit
(vermutlich – ich kenne es nicht selbst) Einsteigern und
Gelegenheitsprogrammierern zu einem schnellen Start.

kamillentee schrieb:
> Man liest immer wieder "Bascom, weils schneller geht". Heutzutage ist
> schnell doch eigentlich das wichtigste! Bascom müßte demnach viel
> populärer sein.
> Warum heißt es hier also immer C ist besser, bzw. wird gegen Bascom
> geflamt (ehrliche Frage)?

Weil es (zu oft) nicht stimmt.

Bascom ist nur dann schneller, wenn man von den mitgelieferten fertigen 
Modulen profitiert. Wenn man etwas erledigen will wofür es kein fertiges 
Modul gibt, geht es entweder langsam oder schlimmstenfalls gar nicht.

Bascom ist vergleichbar mit Fertigteilhäusern. C ist ein Haufen Steine, 
Mörtel und eine Auswahl an Maurerkellen. Assembler ist eine Lehmgrube.

Und so wie es auf dieser Stufenleiter immer mehr einzelne Schritte zum 
fertigen Haus werden, je (scheinbar) einfacher das gewählte Werkzeug 
ist, so steigen andererseits auch die kreativen Möglichkeiten. Aus 
Steinen kann man ein Haus bauen, daß es als Fertighaus nicht gibt. Aus 
Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst 
nicht fertig bekommt.

Axel Schwenke schrieb:
> Aus Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst
> nicht fertig bekommt.

Aber es ist eben noch mehr Aufwand. ;-)

Andererseits kann man gewiss auch im Fertigteilhaus problemlos leben,
sofern man nicht gerade Extrawünsche hat, für die es keine Fertigteile
gibt und die sich auch nicht ohne Weiteres in das Fertigteilkonzept
integrieren lassen.

Axel Schwenke schrieb:

> Bascom ist vergleichbar mit Fertigteilhäusern. C ist ein Haufen Steine,
> Mörtel und eine Auswahl an Maurerkellen. Assembler ist eine Lehmgrube.
>
> Und so wie es auf dieser Stufenleiter immer mehr einzelne Schritte zum
> fertigen Haus werden, je (scheinbar) einfacher das gewählte Werkzeug
> ist, so steigen andererseits auch die kreativen Möglichkeiten. Aus
> Steinen kann man ein Haus bauen, daß es als Fertighaus nicht gibt. Aus
> Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst
> nicht fertig bekommt.

Ach deshalb gibts mittlerweile so viele Fertighäuser :-P

Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht!
Und Zeit ist Geld!

kamillentee schrieb:
> Warum heißt es hier also immer C ist besser, bzw. wird gegen Bascom
> geflamt (ehrliche Frage)?

Ich sehe hier eigentlich viel öfter das Bascom 'Anhänger' gegen alles 
was nicht Bascom ist 'flamen'
Warum eigentlich?

@ Alex W. (a20q90)

>Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht!

Weil du nie eine ordentliche Hochsprache gelernt hast?
Auch wenn C nicht der Weisheit letzter Schluß ist, es ist ein sehr weit 
verbreiteter Industriestandard. Auf den unterschiedlichsten Plattformen, 
vom winzigen uC bis zur fetten Workstation (auch wenn es diesen begriff 
heute so kaum noch gibt). Wenn man die Finger von den linken Tricks in C 
lässt und alles etwas konservativer angeht, kommt man mit C sehr gut und 
schnell zu soliden Ergebnissen.

BASCOM hat schon seine Berechtigung für Anfänger und 
Gegenheitsprogrammierer. Es soll auch Leute geben, die BASCOM in 
größerem Umfang im proifessionelem Umfeld einsetzen. Wenn sie damit gute 
Ergebnisse erreichen, OK. Das Gleiche gilt für Arduino & Co. Mir wären 
aber diverse Einschränkungen zu nervig, allen voran die verkrüppelten 
Formeln mit nur EINER Operation pro Zeile! Wenn es etwas flotter sein 
soll (Interrupts), ist der BASCOM-Compiler nicht so toll, der sicher mal 
pro forma ALLE Register.

@Udo Schmitt (urschmitt)

>Ich sehe hier eigentlich viel öfter das Bascom 'Anhänger' gegen alles
>was nicht Bascom ist 'flamen'
>Warum eigentlich?

Viele Menschen haben einen geistigen Horizont mit dem Radius Null. Das 
nennen sie dann ihren Standpunkt.

Falk Brunner schrieb:
> Weil du nie eine ordentliche Hochsprache gelernt hast?

Das schließt Du woraus?

@ Alex W. (a20q90)

>> Weil du nie eine ordentliche Hochsprache gelernt hast?

>Das schließt Du woraus?

Schrieb ich das nicht?

Beitrag "Re: Ernstzunehmende Programme in BASCOM"

Wie wäre es wenn die BasCom 'Profis' statt sich hier zu zoffen sich mal 
um die Anfragen kümmern, die für bascom hier im Forum reinkommen.
z.B:
Beitrag "Benötige Unterstüzung bei Variablen"

@ Franz (Gast)

>Fragen mit Gegenfragen zu 'beantworten' bringt einen nicht wirklich
>weiter. Wenn du sie einfach beantwortest hättest wäre uns das herumraten
>und Schlussfolgerungen ziehen erspart geblieben.

Nun, für die nicht ganz so auffassungsschnellen.

>> Weil du nie eine ordentliche Hochsprache gelernt hast?

>Das schließt Du woraus?

Das schließe ich aus der Aussage von ihm, die da lautete.

"Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht!"

C ist nicht wirklich langsamer in der Entwicklung, WENN man ein paar 
sinnvolle Codeschnipsel für LCD-Ansteuerung, UART, SD-Karte etc. hat.
Das ist der kleine Vorteil von BASCOM/Arduino etc., dass dort all diese 
Codeschnipsel drinstecken.

> Wie wäre es wenn die BasCom 'Profis' statt sich hier zu zoffen sich mal
um die Anfragen kümmern, die für bascom hier im Forum reinkommen.
z.B:
Beitrag "Benötige Unterstüzung bei Variablen"


Weshalb sollte man jeden Artikel lesen ? Wenn's um Bascom geht koennte 
das auch schon im Titel drin stecken. Das waer effizienter.

Simpel schrieb:
> Es geht auch individuell.

Neugierig:

Warum eigentlich nicht automatisch?  Er sollte doch wissen, welche
Register er zerstört und daher sicher muss.

@ Simpel (Gast)

>Das ist die Default-Einstellung. Es geht auch individuell.
>Optionen:   ...ON interrupt label [NOSAVE|SAVE|SAVEALL]...

Wozu soll ein SAVEALL gut sein?
NOSAVE ist bestenfalls für reine ASM-Funktionen/Interrupts gut.
Was macht SAVE? Intelligent sichern? Warum ist DAS nicht der 
Standardwert?

Jetzt Nicht schrieb:
> Weshalb sollte man jeden Artikel lesen ? Wenn's um Bascom geht koennte
> das auch schon im Titel drin stecken. Das waer effizienter.

Dumme Ausrede, jetzt kennst du den Thread ja, aber du solltest auch 
richtig zitieren lernen.
Ist einfacher als Bascom, einfach Markierenund den richtigen Butten im 
Beitrag unten rechts drücken.

Als typischer Gelegenheitsprogrammierer habe ich meine ein, zwei 
Projekte pro Jahr früher in BASCOM Basic gemacht. Die haben (meistens) 
auch funktioniert und tun das heute noch.

Das auch in diesem Thread angesprochene Ärgernis, dass pro 
mathematischem Ausdruck eine eigene Zeile fällig ist und die 
vorsintflutliche IDE haben mich inzwischen zu LunaAVR geführt. Das ist 
doch schon wesentlich angenehmer! Ach, hätte es das doch schon vor 10 
Jahren gegeben.
Etwas ärgerlich bei Luna sind die Bugs der jeweils aktuellen Betas, da 
suche ich immer wieder Fehler in meinem Code, die in Wirklichkeit im 
Compiler stecken.
Es ist eben noch eine recht junge Sprache. Ich muss aber auch sagen, 
dass die gemeldeten Bugs innerhalb kürzester Zeit abgestellt werden.
Ein Plus bei Luna ist für mich die Nähe zu C (im Vergleich mit Bascom), 
so dass bewährter Code, z.B. die 'Standardlösungen' von Peter Dannegger 
für Tasterentprellung und Drehgeber oder Display Treiber recht einfach 
in Luna übertragen werden kann, wenn man Grundkenntnisse in C hat. Beim 
Bascom Basic fiel mir das noch viel schwerer.

Zusammenfassend kann ich aus meiner Sicht sagen, dass in jeder Sprache 
'ernstzunehmende' Programme geschrieben werden können. Nur muss man sich 
bei manchen Sprachen mehr plagen oder ärgern als bei anderen.
Soll also jeder das Werkzeug benutzen, das für ihn persönlich das 
geeignetste ist.
Allerdings sollte man die verschiedenen Sprachen zumindest oberflächlich 
kennen, wenn man urteilen will.

Erwin Endres schrieb:
> in Plus bei Luna ist für mich die Nähe zu C (im Vergleich mit Bascom),
> so dass bewährter Code, z.B. die 'Standardlösungen' von Peter Dannegger
> für Tasterentprellung und Drehgeber oder Display Treiber recht einfach
> in Luna übertragen werden kann, wenn man Grundkenntnisse in C hat.

Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du 
doch auch in C programmieren.
Warum hast du dann eine ich sag mal so viel exotischere 
Programmiersprache wie Luna gelernt, zumal du selbst schreibst das du 
dann oft Fehler suchst, die nicht in deinem Code sondern an Luna liegen.
In C ist es ziemlich schwer auf einen Bug zu stossen.

Erwin Endres schrieb:
> Soll also jeder das Werkzeug benutzen, das für ihn persönlich das
> geeignetste ist.

Seh ich genauso, allerdings muss eine sachliche Diskussion um Vor und 
Nachteile möglich sein, ohne dass glaich wieder der Kindergarten 
losgeht. Aber das funktioniert leider selten.

Vor einer Stunde habe ich hier auf den Thread verwiesen, in dem ein 
Bascom Anfänger Hilfe benötigt.

Resonanz bis jetzt: NULL!
Versucht zu helfen haben die, die eher wenig mit BasCom zu tun haben.

Traurig
Ihr Nurmis und JetztNichts und bascomnutzer, ...
könnt ihr nur in diesen Diskussionthreads diskutieren oder auch mal 
einem Gleichgesinnten helfen?

Udo Schmitt schrieb:
> Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du
> doch auch in C programmieren.

Nach einem halben Jahr oder längerer Programmierpause fällt es mir 
jedesmal wieder von neuem schwer, mich an die C Syntax zu 
erinnern/gewöhnen. Da ist Luna oder auch Bascom für mich deutlich 
intuitiver.
Außerdem ist es schon zweierlei, ob man einen Algorithmus in eine andere 
Sprache überträgt oder ein komplettes Programm schreibt.

Btw: Die bewährten Peda Routinen sind inzwischen auch in Luna als 
Bibliotheken enthalten.


> Traurig
> Ihr Nurmis und JetztNichts und bascomnutzer, ...
Wie war das mit dem Kindergarten?
Und was sind Nurmis? Finnische Leichtathleten?

Hallo Udo,

Udo Schmitt schrieb:
> Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du
> doch auch in C programmieren.
Die hat er nicht portiert, das war ein anderes Team, die jetzige Lib 
(Interface genannt) ist in Assembler codiert und entsprechend schnell.

PeDa's Drehimpulsgeber Algorithmus zur Auswertung eines Drehencoders 
habe ich gerade für 4 Drehimpulsgeber als Lib (interface) implementiert 
und Mehrfach Drehimpulsgeber (MultiRotaryEncoder) genannt.

> Warum hast du dann eine ich sag mal so viel exotischere
> Programmiersprache wie Luna gelernt, zumal du selbst schreibst das du
> dann oft Fehler suchst, die nicht in deinem Code sondern an Luna liegen.
> In C ist es ziemlich schwer auf einen Bug zu stossen.

Da hast Du bestimmt etwas falsch verstanden, die LunaAVR V2015 R1 Beta 
sind ja genau deshalb veröffentlicht um, Fehler die durch 
Codeoptimierungen entstanden sind, zu finden.
Sie dienen nicht der Programmgenerierung für produktive Projekte.

Die Stabel heißt *LunaAVR V2014 R2.4*
#  http://avr.myluna.de/doku.php?id=de:lunaavr_2014.r2

Uwe S. schrieb:
> Die hat er nicht portiert, das war ein anderes Team, die jetzige Lib
> (Interface genannt) ist in Assembler codiert und entsprechend schnell.

Doch, hat er schon! ;)
Das war bevor die Routinen als Interface zur Verfügung standen...

Mir fällt gerade der Name nicht mehr ein, aber der Typ, der den 
Tricopter gebaut hat, hat auch alles in Basecom geschrieben. Ist alles 
Open Source. Einen Kopter finde ich jetzt schon etwas anspruchsvoller, 
das macht kein Anfänger. Und zu langsam darf die Sprache dann auch nicht 
sein. Achso, der Typ hat auch was mit Biologie studiert und das 
hinbekommen, man muss also nicht immer Informatiker oder E-Techniker 
sein, um etwas "ernsthaftes" auf die Beine zu stellen :-)


Dennis

Erwin Endres schrieb:
> Und was sind Nurmis? Finnische Leichtathleten?

Das waren die Nutzernamen der Nutzer die hier sehr 'aktiv' 'pro BasCom' 
diskutiert haben.

Beispiel:
nurmi schrieb:
> Wenn sich die C-'Profis' um alle C-Probleme kümmern würden, würden sie
> in diesem thread wenigstens nicht stören.

Es fällt mir hier schon länger auf das vor allem bei Themen um BasCom 
schnell sehr hitzig diskutiert wird, wenn aber ein Anfänger mal eine 
Frage stellt, dann findet man praktisch nie diejenigen, die den "Flame" 
Threads den Mund am weitesten aufmachen.
Jetzt habe ich sie praktisch auf den BasCom Thread gestossen, aber 
keiner hat geholfen. Ich selbst kenne etwas Basic von ganz früher auf 
dem PC aber lein BasCom, deshalb kann ich dem genannten Thread nicht 
helfen.

Udo Schmitt schrieb:
> Jetzt habe ich sie praktisch auf den BasCom Thread gestossen, aber
> keiner hat geholfen.

???

Oliver

Oliver S. schrieb:
> ???

Beitrag "Re: Ernstzunehmende Programme in BASCOM"

W.S. schrieb:
> Bascom auf einer anderen
> Platform als AVR geht sicherlich

Ja, geht sicherlich auch 8051 -d.h. nicht nur sicherlich, sondern 
sicher

>Ihr Nurmis und JetztNichts und bascomnutzer, ... könnt ihr nur in diesen 
Diskussionthreads diskutieren oder auch mal einem Gleichgesinnten helfen?

Sorry, ich verwend kein Bascom, dafuer Pascal.

Einen Tiny2313 wuerd ich sein lassen. Hat zu wenig von allem. Allenfalls 
in ASM. Die Kostenersparnis gegen einen vernuenftigen Mega ist marginal.

Jetzt Nicht schrieb:
> Einen Tiny2313 wuerd ich sein lassen. Hat zu wenig von allem. Allenfalls
> in ASM. Die Kostenersparnis gegen einen vernuenftigen Mega ist marginal.

Wenn dann tauscht man ihn gegen einen Tiny84 oder gleich 841. Der 
Vorteil der Tinys im Vergleich zu megas ist die Größe vs. Handlebarkeit.
SOIC ist für viele (auch für mich) ein optimales Gehäuse. Weil es 
relativ klein ist, sich aber sehr prozessicher löten lässt. Sowohl von 
Hand als auch per Hobby-Reflow. Megas bieten sowas nicht. Die sind 
entweder groß, oder haben gleich richtig winzige Gehäuse, welche dann 
oft Probleme beim löten machen.

Ich als Bascomfan siehe ich die Sache so...

Wenn einer ein Quereinsteiger ist wie ich, habe Elektronik nicht 
gelernt, kam ich mit Bascom sehr schnell zum Erfolg.

Sowas wie RGB Steuerung, Uhr, Thermometer usw..was man halt am Anfang 
baut wenn man sich mit uC anfängt.

Wenn ich aber sehe, wieviel Threads existieren "LCD Anzeige nur schwarze 
Balken", oder ADC Werte..dann sehe es ist meistens C. Habe zwar auch mal 
versucht mit C was zu machen, aber mir persönlich ist ein C Code 
schlechter "lesbar"( haufen klammern ) usw aber ist meine persönliche 
Meinung.

Also für Hobby sehe Bascom wirklich super ausreichend.

Die andere Seite wie Industrie ( unsere Zulieferer schreiben 
ausschliesslich in C..) also scheint mir als Industriestandard zu sein.

Ist schon fast wie Microsoft und Linux.

ich komme sehr viel bei Großkunden herum..also keine 100 Man Buden..habe 
NIRGENDS..Linux bisher gesehen , (Windowsserver, Axapta..Office) oder 
sind diese "Free Programme" bisher nicht über den Weg gelaufen, trotz 
daß ich relativ viel in EDV Bereich bzw. Produktion unterwegs bin.

Dann ist die Frage wieder warum :

Industrie - C und Windows
Privat - Linux..naja wer was mag..und wöfür er Geld hat...Lol

drama schrieb:
> Allerdings mit C und nicht BASCOM. :o

Dann ist das für diesen Thread ja völlig unwichtig.

c-hater schrieb:

> Nunja, 2313A und 4313 gibt's nach wie vor in DIP und SOIC. Also genau
> so, wie es sein sollte.

Sagmal hab ich die null gewählt oder warum meldet du dich dauernd von 
den billigen Plätzen? Langeweile?
Dein DIP Gesülze nervt langsam aber sicher. Wenn dir die Features der 
DIP Varianten reichen dann nimm sie. Niemand zwingt dich den 841 zu 
verwenden.
Und den 84 gibts auch in DIP. Dafür hat er 8kb Flash und auch nen 
HW-UART.

m.n. schrieb:
> Aber offensichtlich
> schaffe ich es nicht einen AVR ISP MKII Prommer anzusprechen. Die
> Treiber von AVR Studio reichen wohl nicht und die Nachinstallation von
> USBLIB-Treibern (oder so ähnlich) schaffen auch keine Verbindung. Ich
> weiß nicht wie andere Anfänger damit klarkommen.

Die verwenden einfach die Hilfe, die MCS dafür bereitstellt:
http://avrhelp.mcselec.com/index.html?libusb.htm

Ich sage Dir: Das funktioniert tatsächlich...

m.n. schrieb:
> Aber offensichtlich
> schaffe ich es nicht einen AVR ISP MKII Prommer anzusprechen.

In der Tat..5 Min Google..dann weißt Du ja wie es geht, aber wenn man an 
die Sache eh so rangeht.."ist sowieso nichts"..dann wirds an nicht 
gehen.

Ich habe Bascom und den besagten USB Programmer..null Problem.Win7 64Bit 
Ultimate.

m.n. schrieb:
> Daß man bei einem AVR ISP MKII ein STK500 wählen muß, erschließt sich
> mir allerdings nicht :-(

Nur mal aus Interesse: Was glaubst Du, warum ich den Link zu der
Hilfedatei angegeben habe? Damit Du (immer noch falsch) behauptest,
daß der MK2 als STK500 angesprochen werden soll?

LIES die Anleitung oder schau Dir die Bilder an, falls Du mit dem Text
nicht klarkommst!

m.n. schrieb:
> "Darf man Bascom-Nutzer ernst nehmen?"
> Soll ich darauf antworten?

Darf man Leute ernst nehmen, die nicht mal einen Programmer in Betrieb
nehmen können?

Soll ich darauf antworten?

alt geworden schrieb:
> Jetzt nicht mehr! Ein Forum das nicht mal mehr für Gäste öffentlich
> lesbar ist taugt nicht. Mein Interesse an LunaAVR ist damit auf null
> erloschen. Schade drum!

Eigentlich ist das eher schade für dich.

Aber so ist das, der eine verliert das Interesse an einer Sprache, weil 
er den Programmer nicht zum Laufen bekommt, der andere weil er sich erst 
bei einem Forum anmelden müsste, bevor er dort Rat und Hilfe bekommt.

Häkeln soll ja auch ein schönes Hobby sein...
Obwohl, da muss man Maschen zählen und links und rechts unterscheiden 
können. Oder war das beim Stricken?

m.n. schrieb:
> Daß man bei einem AVR ISP MKII ein STK500 wählen muß, erschließt sich
> mir allerdings nicht :-(

Du kannst mit STK500.EXE prima einen AVRISP MkII ansprechen, unabhängig 
von der benutzten Programmierumgebung (allerdings braucht man MS 
Windows). Hier mal ein Drag&Drop Batchfile, welches einen AT89S52 
programmiert:

1

set prog="C:\xasm\AVR\STK500\Stk500.exe"

2

%prog% -cUSB -dAT89S52 -e -if%1 -pf -vf

3

pause

Da lässt du das Hexfile rauffallen, und der MC wird programmiert.

Ich finde es gut, das Bascom inkl. Compiler und Simulator auch unter 
Linux (mit Wine) funktioniert. Zum Brennen muss man halt avrdude 
verwenden.

Geht das mit AVR Studio auch, oder ist man da imer noch an MS gebunden?

Inline Assembler nutze ich auch, wenn's sehr schnell gehen muss. UNd 
dank Simulator sieht man auf den Takt genau und für jede Programmzeile, 
wie das Programm nachher läuft, wo er die Variable im Ram hinschreibt, 
wie die Register belegt sind etc.

Ist mir "ernsthaft" genug. ;-)

Rainer, lern erstmal den Unterschied zwischen IDE und Toolchain bevor du 
dich in Diskussionen um Bascom, C und Assembler stürzt.

Die avr-gcc Toolchain um AVRs in C zu programmieren gibts natürlich auch 
für Linux. Das brauchts kein Wine. Und Eclipse läuft da auch nativ. Das 
Atmel Studio hat damit wenig zu tun.

Aber die Tatsache dass Bascom nur auf Windows oder eben in Wine läuft, 
als pro-Argument für Bascom herzunehmen, weil es so toll unter Linux 
läuft, dazu gehört schon Chuzpe.

Falk Brunner schrieb:
> @ Simpel (Gast)
>
>>Das ist die Default-Einstellung. Es geht auch individuell.
>>Optionen:   ...ON interrupt label [NOSAVE|SAVE|SAVEALL]...
>
> Wozu soll ein SAVEALL gut sein?
> NOSAVE ist bestenfalls für reine ASM-Funktionen/Interrupts gut.
> Was macht SAVE? Intelligent sichern? Warum ist DAS nicht der
> Standardwert?

SAVE ist der Standardwert, das hatte Simpel flasch aufgeschrieben.
.
Quelle, Bascom hilfe:
Store: This is the default and is the same as when no parameter is 
provided. The most common used registers, SREG, and RAMPZ are saved and 
restored.
Saved : SREG , R31 to R16 and R11 to R0 with exception of R6,R8 and R9.
If RAMPZ exists, it will be saved as well.

Saveall: This will save all registers that SAVE will save, but it will 
also save R12-R15. You should use this option when using floating point 
math in the ISR.

Sogesehen wird fast alles gesichert, aber man kann das eben 
beeinflussen.

bye uwe

Uwe R. schrieb:
> Sogesehen wird fast alles gesichert, aber man kann das eben
> beeinflussen.

Beantwortet aber noch nicht die Frage, warum nicht genau das
gesichert wird, was auch in der Funktion benutzt wird.

Ich mein', so macht das jeder andere Compiler auch …

Jörg Wunsch schrieb:
> Uwe R. schrieb:
>> Sogesehen wird fast alles gesichert, aber man kann das eben
>> beeinflussen.
>
> Beantwortet aber noch nicht die Frage, warum nicht genau das
> gesichert wird, was auch in der Funktion benutzt wird.
>
> Ich mein', so macht das jeder andere Compiler auch …

Hmm, wäre keine schlechte sache, stimmt.

Halten wir erstmal fest: die Aussage das immer alle Register gesichert 
werden ist falsch. Stattdessen werden viele gesichert, man kann es aber 
auch ganz abschalten und nur die benötigten sichern. Die muss man dann 
aber genau kennen (sollte in kritischen Assemblerfunktionen gegeben 
sein).
Ein Automatismus wäre wünschenswert und würde Zeit/Fehlerquellen sparen.
Es geht aber ganz manuell (mit Lehmgrube sozusagen ;o)).

bye uwe

>Beantwortet aber noch nicht die Frage, warum nicht genau das
>gesichert wird, was auch in der Funktion benutzt wird.
>
>Ich mein', so macht das jeder andere Compiler auch …

Nein tut er nicht. Banale Ausrede der Compilerbauer: Es kann nicht 
vorhergesehen werden was Funktionsaufrufe alles mit sich ziehen.
Denn es gibt Leute, die spulen umfangreiche Switch/Case Konstrukte ab. 
Das muss dann nicht zwingend lange Ausfuehrungszeiten nach sich ziehen, 
ist aber nicht mehr mit einem Ein- oder Zweipasscompiler machbar. Da 
waer dann Backtracking angesagt.

Ich haett auch erwartet, bei einer kurzen ISR, in der vielleicht ein 
Zaehler incrementiert, ein Flag gesetzt, ein Register geladen wird, 
waere es moeglich nach Bedarf zu sichern.

Jetzt Nicht schrieb:
> Banale Ausrede der Compilerbauer: Es kann nicht vorhergesehen werden was
> Funktionsaufrufe alles mit sich ziehen.

Dass man bei Funktionsaufrufen alle Register sichern muss, die
per ABI als durch den Aufrufer zu sichernd festgelegt sind, ist
logisch.  Aber ob es überhaupt einen Funktionsaufruf gibt, kann
ein Compiler natürlich schon merken, und wenn es keinen gibt, dann
hat er einen guten Überblick, welche Register er selbst tatsächlich
zerstört.

> Denn es gibt Leute, die spulen umfangreiche Switch/Case Konstrukte ab.
> Das muss dann nicht zwingend lange Ausfuehrungszeiten nach sich ziehen,
> ist aber nicht mehr mit einem Ein- oder Zweipasscompiler machbar.

Das ist 'ne lahme Ausrede.  Ein GCC ist auch ein Einpasscompiler.
Beweis:

1

% avr-gcc -Os -x c -mmcu=atmega8 -o - -S -

2

#include <avr/io.h>

3

#include <avr/interrupt.h>

4

uint16_t adcval;

5

6

ISR(ADC_vect)

7

{

8

  adcval = ADC;

9

}

10

^D

11

        .file   ""

12

__SP_H__ = 0x3e

13

__SP_L__ = 0x3d

14

__SREG__ = 0x3f

15

__tmp_reg__ = 0

16

__zero_reg__ = 1

17

        .text

18

.global __vector_14

19

        .type   __vector_14, @function

20

__vector_14:

21

        push r1

22

        push r0

23

        in r0,__SREG__

24

        push r0

25

        clr __zero_reg__

26

        push r24

27

        push r25

28

/* prologue: Signal */

29

/* frame size = 0 */

30

/* stack size = 5 */

31

.L__stack_usage = 5

32

        in r24,0x4

33

        in r25,0x4+1

34

        sts adcval+1,r25

35

        sts adcval,r24

36

/* epilogue start */

37

        pop r25

38

        pop r24

39

        pop r0

40

        out __SREG__,r0

41

        pop r0

42

        pop r1

43

        reti

44

        .size   __vector_14, .-__vector_14

45

        .comm   adcval,2,1

46

        .ident  "GCC: (GNU) 4.7.2"

47

.global __do_clear_bss

(Mir geht es hier ausdrücklich nicht um die Sprache C, sondern
um das Verhalten des Compilers.  C als Eingabe dient nur als
einfach zu handhabendes Beispiel.)

Der Compiler liest direkt von der Standardeingabe, da kann er also
nicht zweimal darüber iterieren, denn nachdem er ein Zeichen gelesen
hat, ist es unwiederbringlich weg aus dem Eingabestrom.

Trotzdem kann er die benutzten Register optimieren.  (r0/r1 optimiert
er nicht, sondern das ist eine Art Standard-Prolog/Epilog, durch die
Sonderrolle dieser Register für den AVR-GCC bedingt.  Ja, das ist
verschenktes Optimierungspotenzial.)

Wenn GCC jetzt ein BASIC-Frontend hätte, könnte er auch in dieser
Sprache vergleichbares Optimierungspotenzial anbieten, denn die
Optimierung läuft ja viel weiter hinten ab.

Schicke Gerätebibliotheken kann man auch durchaus unabhängig von der
benutzten Programmiersprache anbieten; die Arduino-Umgebung ist der
beste Beweis dafür (und sicher auch ein Grund, warum diese Plattform
bei vielen beliebt ist).

> Ernstzunehmende Programme in BASCOM

ich hab nicht mal MINI code-beispiele von irgnedwelchen Programmen 
gefunden
(immer nur mini-turtorials die kaum über blink.bas hinausgehen..)

kann mir wer helfen, würde mir bascom gerne anschauen

die kombi, BASCOM und Arduino klingt theoretisch ja recht interessant, 
z.b. für Kinder zum Anfangen ?!

(für mich ist BASIC immer wesentlich kompliziert gewesen als alles 
andere, z.b. musste ich mal Windows Scripts (WSH oder auch Excel) in 
Basic schreiben/erweiter .. z.B. WANN man da genau Klammer setzten 
muss,bei funktionsaufrufen, und wann nicht, ist mir bis heute unklar...)

Robert L. schrieb:
> kann mir wer helfen, würde mir bascom gerne anschauen

Ja, Du Dir selbst, indem Du dort hingehst:


Hier ein Link
zur Codesammlung von MCS-Electronic (Hersteller von Bascom). Dort
kannst Du auch ziemlich umfangreiche und anspruchsvolle Aufgaben-
lösungen finden:

http://www.mcselec.com/index.php?option=com_conten...

Edith sagt: Die Seite läßt keine tiefen Links zu, Du kannst über
Applikation-> Bascom AVR zu der Quelltexctsammlung gelangen.

Falk Brunner schrieb:
> Wenn es etwas flotter sein
> soll (Interrupts), ist der BASCOM-Compiler nicht so toll, der sicher mal
> pro forma ALLE Register.

Was man aber abschalten kann.

Ich frage mich wirklich warum dieses Null-Argument immer wieder 
auftaucht.
Aber daran kann man wenigstens leicht erkennen wer sich wirklich damit 
befasst hat.

Bernd T. schrieb:
> Aber daran kann man wenigstens leicht erkennen wer sich wirklich damit
> befasst hat.

An deinem Kommentar erkennt man dafür, dass du den Rest des Threads
nicht gelesen hast …  Nein, ein „Null-Argument“ ist das nun nicht
gerade.

danke Paul Baumann
diese Seite hab ich zwar per google auch ein paar mal entdeckt, aber 
nicht ernst genommen/ignoriert (aufgrund der Optik)

auch mit deiner Anleitung viel es mir schwer dort, Beispiele zu finden 
(habs dann aber geschafft, auch wenn einige "russich" kommentiert sind, 
oder zumindest mein Text-Editor kuriose Zeichen anzeigt?!)


egal: mir (Programmieren, Pascal, C usw) scheint das ganze extrem 
"kompliziert" zu sein (in mehrerlei Hinsicht)
da Frage ich mich ernsthaft wie ein "Anfänger" da was zustande bringen 
soll..

die Zielgruppe scheint eher "Lötkolbenspezialisten" zu sein, die (noch) 
nicht Programmieren können...

Seit es Arduinos gibt, kannst das imho getrost vergessen..

Robert L. schrieb:
> da Frage ich mich ernsthaft wie ein "Anfänger" da was zustande bringen
> soll..
>
> die Zielgruppe scheint eher "Lötkolbenspezialisten" zu sein, die (noch)
> nicht Programmieren können...

Du widersprichst Dir gleich im darauffolgenden Satz, merkst Du das 
nicht?

Robert L. schrieb:
> Seit es Arduinos gibt, kannst das imho getrost vergessen..

Das kannst Du vergessen, daß Du das vergessen kannst.
;-)

Die "Arduino-Sprache" ist auch ein C-artiges Ding. Wer das nicht will,
der benutzt weiter Bascom. Schon alleine die Bedienoberfläche ist viel
komfortabler und auch ziemlich umfangreich. Damit kann sich die Arduino-
Oberfläche nicht messen.

MfG Paul

@ Paul Baumann (paul_baumann)

>Die "Arduino-Sprache" ist auch ein C-artiges Ding.

Es IST einfaches, im Sprachumfang reduziertes C++. Wobei niemand 
gehindert wird, mehr zu nutzen, der Compiler dahinter kann es (99,9% der 
Anwender allerdings nicht, ich auch nicht).

> Damit kann sich die Arduino-
>Oberfläche nicht messen.

findest?

http://www.visualmicro.com/page/Arduino-for-Atmel-Studio.aspx

;-)


>Du widersprichst Dir gleich im darauffolgenden Satz, merkst Du das
>nicht?

ja aber auch nein:
ich implizierte, dass sich inzwischen auch der 
"Lötkolbenspezialist"/Programmieranfänger es nicht selber schwer machen 
wird und einen  "großen" µC verwenden und einen Haufen "Krempel" 
rundherum löten wird
wenn er einen auch nicht größeren Arduion Pro/micro/nano/mini nehmen 
kann und dort  (s)einen Haufen "Krempel" rundherum lötet...

BASCOM: rickshaw
C: fahrrad

noch fragen...


ernsthaft: ICH schreibe z.B: C Code auch einfach so (quasi "Pascal 
ähnlich), dass ICH ihn wieder leichter lesen kann, und lasse viele 
"Features" absichtlich aus ..
das was ich bisher in BASCOM gesehen hab, war mehr als kryptisch ..

anderen Code lesen, muss ein "Anfänger" eh nicht
und ob das bei den ASM libraries von Bascom einfacher ist??

Robert L. schrieb:
> findest?

Ja, das finde ich.

Robert L. schrieb:
> ich implizierte, dass sich inzwischen auch der
> "Lötkolbenspezialist"/Programmieranfänger es nicht selber schwer machen
> wird und einen  "großen" µC verwenden und einen Haufen "Krempel"
> rundherum löten wird
> wenn er einen auch nicht größeren Arduion Pro/micro/nano/mini nehmen
> kann und dort  (s)einen Haufen "Krempel" rundherum lötet...

So, implizierst Du...

Es ist auch möglich jedweden Arduino aus Bascom heraus zu programmieren.

Aber gut: Ich merke, daß Du Recht haben willst und siehe da -Ich gebe
Dir Recht.

Ja, weil ich alt genug bin, um einzusehen, daß man Niemanden von seiner
einmal gefassten Ansicht abbringen kann.

MfG Paul

Old Papa schrieb:
> Hallo ich kann einigermaßen mit einem Fahrrad (Bascom) umgehen. Warum
> soll ich unbedingt auf ein Einrad (C..) umsteigen?

Wenn Bascom ein Fahrrad ist, müsste dann C nicht eher ein Motorrad sein?

Denn:

- Ein Motorrad ist schneller als ein Fahrrad.

- Wenn man mit dem Motorrad halbwegs umgehen kann, ist es auch weniger
  anstrengend.

- Als Fahranfänger wird man das Motorrad ständig umschmeißen und darüber
  fluchen, dass es so schwer wieder aufzustellen ist.

- Wer noch nie Motorrad gefahren ist, sollte erst einen Blick ins
  Handbuch werfen, um danach Dinge wie Kupplung und Schaltung so
  bedienen zu können, dass sie nicht gleich kaputt gehen.

- Fahrfehler haben auf dem Motorrad meist schlimmere Folgen als auf dem
  Fahrrad.

ernstzunehmende Programme kann man in jeder Sprache schreiben.

Da ich von Python und anderen Sprachen verwöhnt war, hatte ich beim 
Beginn mit Mikrocontrollern keinen Bock auf das damals noch nötige 
Zusammensuchen von GCC+IDE+libs. Stattdessen habe ich mit Bascom 
angefangen und bin dabei hängen geblieben, siehe: 
http://www.photonenhuette.de -> Anlage -> Programm.

Bascom hat den Vorteil, das es viele Funktionen mitliefert, andererseits 
ist Basic nicht gerade förderlich um größere Projekte brauchbar zu 
modularisieren

alt geworden schrieb:
> Jetzt nicht mehr! Ein Forum das nicht mal mehr für Gäste öffentlich
> lesbar ist taugt nicht. Mein Interesse an LunaAVR ist damit auf null
> erloschen. Schade drum!

ich begreife hier nicht wieso man sich dann nicht einfach einen 
Instant-Account bei gmail o.Ä. macht und sich anmeldet wenn es dir denn 
sooo wichtig ist. Diese ganze Argumentation ist absoluter Nonsense.

Ich betreibe auch ein Forum für unseren Verein und wenn nicht 
sicherzustellen ist das man jeden Tag auf irgendwelche juristisch 
problematische Beiträge prüfen kann, muss man das Ganze einfach zur 
eigenen Sicherheit nicht-öffentlich machen. So habe ich das dann auch 
gemacht. Die entsprechende Gesetzgebung und die Pflichten dazu hast du 
demnach noch nicht zu Gesicht bekommen wie mir scheint.

Das es genügend Bekloppte gibt (MWS wird z.B. komplett 
ignoriert/ausgeblendet, ich will gar nicht wissen was die Tütensuppe 
schreibt), sieht man ja an diesem Forum. Die Moderatoren haben hier 
reichlich zutun.

Ehrhardt Balstein schrieb:
> muss man das Ganze einfach zur eigenen Sicherheit nicht-öffentlich
> machen.

Das mag für eine kleine geschlossene Benutzergruppe wie deinen Verein
passen, aber für etwas wie LunaAVR, bei der du ohnehin nicht mehr
jeden persönlich kennst, ist das Augenauswischerei. Wenn ich mich
(deine Argumentation) mit einem Instant-Account da drumrum mogeln
kann, dann kann man den Quatsch auch sein lassen, und jeden das
Forum dort lesen lassen.

> Wenn ich mich
> (deine Argumentation) mit einem Instant-Account da drumrum mogeln
> kann, dann kann man den Quatsch auch sein lassen, und jeden das
> Forum dort lesen lassen.

 Eine notwendige Anmeldung zum Lesen ist juristisch "nicht öffentlich". 
Nehmen wir an irgendein Fanatiker kommt auf die Idee hier in das Forum 
einen Beitrag zu schreiben der zu einem Anschlag aufruft. Wenn der 
Betreiber des Forums wie es in meinem Fall nur ich bin nicht 
schnellstens darauf reagieren kann, kann man sich recht schnell 
mitstrafbar machen. Hier macht es dann den entscheidenden Unterschied ob 
das Ganze öffentlich war oder nicht und das entscheidet dann auch im 
schlimmsten Fall ob man kriminalisiert wird oder nicht.

Nun ist dieses Beispiel natürlich überzeichnet und mag am Ende des 
Spektrums liegen, aber die Abstufung bis zu "harmlos" ist sehr breit. 
Nicht jeder Forenbetreiber hat die Zeit und Muße und einen Wald voller 
Moderatoren. Ich bin auch seit Jahren erstaunt das man z.B. hier 
immernoch als Gast posten darf. Irgendwann wird den Moderatoren 
vieleicht dann doch mal was durch die Lappen gehen, was sicher einen 
Lernprozess zur Folge hätte. Zu wünschen ist es dem Betreiber nicht.

Ich kann mir gut vorstellen, das es bei anderen Foren ähnlich gelagert 
ist wie bei meinem Vereinsforum.

Frank Esselbach schrieb:
> Ob ein Programm "ernsthaft" ist oder nicht, macht sich nicht an der
> Programmiersprache fest. Nur weil eine bestimmte IDE es erlaubt,
> unübersichtlich und liederlich zu progrsammieren, muss man das ja nicht
> so machen.

Was hat jetzt genau die IDE damit zu tun? Es liegt wenn, dann schon an 
der Sprache selbst. Die IDE tut da nichts zu.

Es kommt darauf an, was man von der Sprache erwartet. Abgesehen vom 
abgedroschenen "es liegt alles nur am Programmierer", was so natürlich 
auch nicht stimmt, bieten verschiedene Sprachfamilien, verschiedene 
Features.

Dabei ist der eigentliche Syntax (vulgo "Syntaktischer Zucker") völlig 
egal. Die höheren Konstrukte wiederrum nicht.

BASIC Dialekte bietet vor allem eines, eine sprechende Syntax. D.h. viel 
tippen für wenig Substanz. Dafür sieht der Code vielleicht für Anfänger 
schöner aus, die Syntax lässt sich leichter merken. Es fehlen 
kompliziert anmutende Sonderzeichen wie geschweifte Klammern oder 
Semikolons. Das alles ändert Objektiv nichts, hat aber subjektiven 
Einfluss und wird als leichter empfunden.

Aber gerade BASCOM offenbart einige große Schwächen. Es sind (oder waren 
zumindest) nicht beliebig komplexe Ausdrücke möglich. Und das ist ein 
No-Go für eine ernstzunehmende Programmiersprache. Dazu kommen eigene 
(zusammengesetzte) Datentypen, die praktisch nicht existent sind. Das 
sind nur 2 Punkte einer ganzen Liste.
Ein erfahrener Programmierer erkennt hier, dass man so für viele 
Probleme keine elegante oder saubere Lösung realisieren kann, egal wie 
gut man ist.

Die vielgescholtene Pointerarithmetik von C, offenbart dem Programmierer 
auf elegante Weise viele Möglichkeiten ohne dafür viel Syntax aufwenden 
zu müssen. Es lassen sich viele Konzepte (auch OO) recht gut umsetzen 
ohne dass die Sprache selbst dafür Konstrukte enthalten muss. Bei allen 
Schwächen die nackte Pointer mitbringen (no seatbelts), die aber für 
eine hardwarenahe Entwicklung dennoch wünschenswert sind.

Fazit:
"Ernstzunehmend" ist sehr subjektiv und nicht zu definieren. Wem der 
BASIC Syntax gefällt, und nicht an die Grenzen der Sprache stößt (weil 
die Programme einfach bleiben oder er es nicht anders kennt), der ist 
mit BASCOM glücklich.
Wer besseres kennt, der erkennt zu schnell den Käfig den BASCOM um das 
eigene Programm errichtet.

Timm T. schrieb:

> Ja, wunderbar. Diesem tollen C haben wir so ziemlich sämtliche
> Einfallstore zu verdanken, die mit Buffer-Overflows, Pointern, zu langen
> Strings usw. in den letzten Jahren aufgetreten sind.

Meinst du, das wäre bei den alten Assemblerprogrammen (für deren
Ablösung C letztlich verantwortlich ist) besser gelaufen?

> Was unter Basic oder Pascal überhaupt nicht möglich wäre, weil da
> einfach sauberer deklariert und geprüft wird,

Auch beim typischen Pascal-Programm wurde das bounds checking für
gewöhnlich nur während der Entwicklungsphase benutzt, aber bei
Auslieferung aus Performancegründen deaktiviert.  Damit bist du dann
kaum besser dran als bei C.  Wenn die Bugs schon während der
Entwicklung aufgetaucht wären, dann hätten sie wohl auch die von dir
gescholteten C-Programmierer von vornherein beseitigt.

Inwiefern BASIC-Dialekte vie Bascom, um das es hier ja geht, in der
Tat noch Laufzeit-Boundarychecks machen, entzieht sich meiner Kenntnis.

Timm T. schrieb:
> Aber ist ja cool und 1337, den Code so unübersichtlich wie möglich zu
> machen. Und Bounds prüfen ist was für Weicheier.

Hmm also ich sprach von "elegantem Code". Wie du da jetzt auf 
unübersichtlich kommst verstehe ich nicht.
Billige Polemik? Ja ich glaube so ist es.

Und Boundary Prüfung zur Laufzeit bläht dir viel Code in dein Projekt. 
Wie soll das bei kleinen Controllern gehen? Das will man meist nicht. 
Natürlich wäre es schön zu haben, bei einem ausgewachsenen PC Programm 
das mit zig MB Binarys daherkommt und sich mal schnell 500MB Speicher 
reserviert sieht das vielleicht anders aus. Aber dann nimmt eine andere 
Sprache, welche die Sicherheitsfunktionen bietet, die man will. C bietet 
sie nicht. Aber das ist Absicht.

Timm T. schrieb:
> Bitte? Ich mache auf dem AVR immer Bound Checking bei Benutzereingaben
> oder Daten, die über Uart reinkommen.

Das kannst du doch nicht mit einem eingebauten Boundary Check für alle 
Arrays vergleichen... Dazu braucht man komplexe Datenstrukturen für 
jedes Array, inkl. Funktionen die darauf arbeiten. Bei JEDEM Zugriff. 
Heute ist ein Array nichts anderes als ein Pointer an das 1. Element. 
Ich denke du übersiehst den Aufwand deiner eigenen Forderungen nicht 
wirklich.
Hast du mal näher mit solchen Konzepten auf Compiler bzw. Laufzeitbasis 
beschäftigt?

Mir kommen solche Forderungen immer etwas blauäugig vor. Als würde man 
den Tischlerhobel kritisieren, weil der so scharf ist und außerdem kann 
man damit ganz üble Macken in die Möbel machen. Man benötigt manchmal 
auch derbes Handwerkszeug (C) für manche Aufgaben oder will es nutzen, 
und nicht nur die große schwere teure CNC Maschine.

> Nimmt man anscheinend nicht, sonst würde es nicht regelmäßig darauf
> beruhende gravierende Sicherheitslecks geben. Das fängt schon mit der
> bescheuerten Idee der nullterminierten Strings an...

Auch hier müsste sonst eine spezielle String-Datenstruktur in der 
Sprache eingebaut sein. Aber du kannst doch eine solche Struktur 
einführen in deinen Projekten. Nur warum muss man das alles zwingend in 
die Sprache selbst reinpacken?

C ist hardwarenah geplant. No Seatbelts ist ein Feature. Keine 
Einschränkung. Auf kleinen Controllern machen deine Sicherheitskonzepte 
keinen Sinn. Der Code dafür würde manchen AVR Flash bereits sprengen.

Timm T. schrieb:
> Ich mache auf dem AVR immer Bound Checking bei Benutzereingaben oder
> Daten, die über Uart reinkommen.

Dann schau dir doch bitte mal die Bugs an, die du kritisiert hast.

Nein, an einer Überprüfung externer Eingaben liegt das in aller
Regel nicht.  Das sind deutlich subtilere Fallen, in die da getappst
wird.

Keiner behauptet, dass C der Stein der Weisen sei.  Aber ehrlich, wenn
wir außer C nur BASIC gehabt hätten, dann würden Betriebssysteme wohl
auch heute noch in Assembler geschrieben werden, so wie es vor C und
UNIX gang und gäbe war.  Ob das nun sicherheitsmäßig wirklich besser
gewesen wäre, wage ich mehr als zu bezweifeln.

Timm T. schrieb:
> Cyblord -. schrieb:
>> Bei JEDEM Zugriff.
>> Heute ist ein Array nichts anderes als ein Pointer an das 1. Element.
>
> Doch ja, natürlich.
In C meine ich.

Da ist ein Array ein Pointer auf das 1. Element. Thats it. Fertig. Aus.

> Das Array hat eine Größe, und es wird geprüft, ob
> die angesprochene Adresse innerhalb des Arrays liegt. Wenn nicht, gibts
> schlimmstenfalls einen Programmfehler, aber es wird nicht außerhalb des
> Arrays geschrieben. Das machen Basic und Pascal genau so.

Ist aber zur Laufzeit mit extremem Overhead verbunden. Und bringt auf 
Controllern wenig. Was soll das Programm tun wenn es eine illegalen 
Zugriff erkennt?

>
> Das kann man bewußt umgehen, wenn man mehr Peformance will. Aber dann
> muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei

Nein im Gegenteil. Man muss die Prüfung bewusst EINBAUEN. Mit viel Code.

Timm T. schrieb:

> Aber dann
> muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei
> C.

Das wesentliche Manko an C ist es, die Längeninformation des Arrays
nicht mit durchzureichen, sodass die Implementierung einer solchen
Prüfung nicht problemlos möglich ist.

> Jörg W. schrieb:
>> Nein, an einer Überprüfung externer Eingaben liegt das in aller
>> Regel nicht.
>
> Dochdoch, wenn ein Webbrowser / Mediaplayer zuläßt, daß eine Webadresse
> / ein Filename so lang ist, daß ein Teil des Strings im ausgeführten
> Speicherbereich landet,

Du solltest dich mal davon verabschieden, dass nach derart primitivem
Muster noch nennenswert was passiert.  Ja, auch sowas kommt vor, aber
das meiste sind irgendwelche race conditions oder viel subtilere
buffer overflows als die, die man mit so einer primitiven Methode
bereits hätte erkennen können.  Besonders „beliebt“ sind integer
overflows, aber gerade hier hättest du ein mächtiges Problem mit der
Performance, wenn du bei jeder Multiplikation vorab die Argumente
überprüfen willst.

>> Aber ehrlich, wenn
>> wir außer C nur BASIC gehabt hätten, dann würden Betriebssysteme wohl
>> auch heute noch in Assembler geschrieben werden
>
> Du solltest Dich mal von der Vorstellung verabschieden, daß Basic im
> Interpreter läuft, lahm ist und nix kann. Das stimmt schon seit 20
> Jahren nicht mehr.

Nichtsdestotrotz kann ich mir in BASIC beim besten Willen kein OS
vorstellen.  Da fehlen einige Features, auf die man in C von
vornherei geachtet hat, indirekte Funktionsaufrufe beispielsweise.
Hat BASIC inzwischen Datestrukturen?

Vor 45 Jahren jedenfalls (als C angetreten ist, den Assembler beim
OS abzulösen) war da wohl weit und breit nichts dergleichen, und auch
die von dir genannten 20 Jahre helfen da nicht – da waren die Messen
bereits gesungen.  Pascal war einigermaßen parallel entstanden, aber
halt als Lehrsprache, weshalb gezielte Typumwandlungen eben auch dort
fehlen.

Timm T. schrieb:

> Doch ja, natürlich. Das Array hat eine Größe, und es wird geprüft, ob
> die angesprochene Adresse innerhalb des Arrays liegt.

Das kann man machen, solange man noch weiss, dass man es mit einem Array 
zu tun hat. Aber spätestens, wenn man dann mit Arrays und Funktionen 
arbeitet, ist dem in C nicht mehr so. Da verschwimmen die Grenzen. Und 
das ist ganz bewusst so gemacht worden.
Daher ist in C ein nicht gemachter Bounds Check kein vergessenes Feature 
sondern ist schlicht und ergreifend nicht möglich. Dazu müsste man die 
Sprache in wesentlichen Bereichen komplett umbauen.

> Das kann man bewußt umgehen, wenn man mehr Peformance will. Aber dann
> muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei
> C.

Sicherlich.
Wer die Tante zum Lulu gehen braucht, für den ist C die falsche Sprache. 
Hier ist schon der Entwickler gefragt, sorgfältig zu arbeiten. Das 
wiederum, da bin ich ganz bei dir, geht öfter schief als einem lieb ist.
Die Intention von C war von vorne herein keine Sprache mit 
Sicherheitsnetz sondern ein "You asked for it, you got it"

Es gibt nur 2 mögliche Auswege
* eine andere Sprache nehmen
* die 'ich kann nur 20% von C aber mehr interessiert mich nicht' 
Fraktion der Jungprogrammierer von der ernsthaften Entwicklung 
fernhalten, bis sie erwachsen geworden sind und nicht nur ihre Rechte 
sondern auch ihre Pflichten kennen, denen sie sich mit der 
Programmierung in C unterwerfen.