|
Anzeige
|
ADA Spezifikationen / Programming Reference
Gast
#2252928
Moin, suche Spezifikationen und Referenzen zu ADA. Ziel sollte es seinen in weit entfernet Zukunft einen Compiler für 8 Bitter zu entwickeln. Ganz ähnlich AVR-ADA. Ich suche daher sozusagen alle Spezifikationen also auch Verifikation, Laufzeittests, parallele Verarbeitung, Ausnahmebehandlung, generische Systeme, etc ... guten Tag noch Danke Ich hab mal so ein Ringheft angeschafft. Mittlerweile gibt's das auch gebunden. Schau beim Buchhaendler deiner Wahl unter "Ada reference manual" oder so. Ich find da einige Eintraege.
Gast
#2252979
Habe einfach mal danach gesucht und folgendes gefunden: http://www.ada-auth.org/arm.html ist das das richtige? Dieter K. schrieb: > Moin, > suche Spezifikationen und Referenzen zu ADA. Ziel sollte es seinen in > weit entfernet Zukunft einen Compiler für 8 Bitter zu entwickeln. Sicher? > Ganz ähnlich AVR-ADA. Ich suche daher sozusagen alle Spezifikationen also > auch Verifikation, Laufzeittests, parallele Verarbeitung, > Ausnahmebehandlung, generische Systeme, etc ... > > guten Tag noch Danke Das ALRM wurde doch gefunden http://www.adaic.org/resources/add_content/standards/05rm/RM-Final.pdf Die Tests könnte man dort auch finden http://www.ada-auth.org/acats.html Für den älteren 95er Standard gibt's eine fertige EBNF http://www.cs.vu.nl/grammarware/ada/ Theoretische Grundlagen? Compilerbau, Typentheorie etc.? Zurueck zum ersten Post. Heutzutage sollte man so eine Arbeit fuer einen 32 Bitter anpeilen. Man moechte trotz der Laufzeit Tests und dergleichen noch eine vernuenftige Performance, die etwas ueber einer Relaisschaltung liegt, erreichen. Und der Codespace sollte nicht ausschliesslich vom System beansprucht werden.
Gast
#2253028
Arc Net schrieb: > Dieter K. schrieb: >> Moin, >> suche Spezifikationen und Referenzen zu ADA. Ziel sollte es seinen in >> weit entfernet Zukunft einen Compiler für 8 Bitter zu entwickeln. > > Sicher? Ja. Ich sage ja in ferner Zukunft! Arc Net schrieb: > Das ALRM wurde doch gefunden > http://www.adaic.org/resources/add_content/standar... > Die Tests könnte man dort auch finden > http://www.ada-auth.org/acats.html > Für den älteren 95er Standard gibt's eine fertige EBNF > http://www.cs.vu.nl/grammarware/ada/ Dankeschön - genau das habe ich gesucht. Arc Net schrieb: > Theoretische Grundlagen? Compilerbau, Typentheorie etc.? Grundlagen sind vorhanden - Potenzial nach oben ist mit Sicherheit noch vorhanden. Oktav Oschi schrieb: > Heutzutage sollte man so eine Arbeit fuer einen > 32 Bitter anpeilen. Man moechte trotz der Laufzeit Tests und dergleichen > noch eine vernuenftige Performance, die etwas ueber einer > Relaisschaltung liegt, erreichen. Und der Codespace sollte nicht > ausschliesslich vom System beansprucht werden. Da ist was dran. Auch wenn es hier nicht gerne gesehen ist -> ich peile in Richtung PIC18, nach oben kann man da natürlich auch was machen. Zum Einstieg soll zuerst sollte das ganze mal für die relativ einfachen PIC18 realisiert werden. Dieter K. schrieb: > Da ist was dran. Auch wenn es hier nicht gerne gesehen ist -> ich peile > in Richtung PIC18, nach oben kann man da natürlich auch was machen. Zum > Einstieg soll zuerst sollte das ganze mal für die relativ einfachen > PIC18 realisiert werden. Falscher Fehler... Die Architekturen eines ARM7 oder auch PIC32/MIPS4k sind dafür ausgelegt...Keine unterschiedlichen/getrennten Adressbereiche (Program/Daten/SFR), keine Bankumschaltungen wie beim PIC18, keine unterschiedlichen Zeigertypen/größen, die verwaltet werden müssen usw.
Gast
#2253149
Arc Net schrieb: > Die Architekturen eines ARM7 oder auch PIC32/MIPS4k sind dafür > ausgelegt...Keine unterschiedlichen/getrennten Adressbereiche > (Program/Daten/SFR), keine Bankumschaltungen wie beim PIC18, keine > unterschiedlichen Zeigertypen/größen, die verwaltet werden müssen usw. Hmmm ok ^^ Bankumschaltung gibt es bei PIC18 nichtmehr - das war PIC16. Das andere ist natürlich schon zu bedenken ... Dieter K. schrieb: > Arc Net schrieb: >> Die Architekturen eines ARM7 oder auch PIC32/MIPS4k sind dafür >> ausgelegt...Keine unterschiedlichen/getrennten Adressbereiche >> (Program/Daten/SFR), keine Bankumschaltungen wie beim PIC18, keine >> unterschiedlichen Zeigertypen/größen, die verwaltet werden müssen usw. > > Hmmm ok ^^ > > Bankumschaltung gibt es bei PIC18 nichtmehr - das war PIC16. Das andere > ist natürlich schon zu bedenken ... Der PIC18 hat unterschiedliche Bänke 1), wenn ich das auf die schnelle richtig gelesen habe (TABLE 26-2), gibt's auch nur MOVFF um Bytes direkt in den gesamten 4k umzukopieren, die restlichen Befehle arbeiten in/mit der ausgewählten Bank. 1) "5.3.2 BANK SELECT REGISTER (BSR) Large areas of data memory require an efficient addressing scheme to make rapid access to any address possible. Ideally, this means that an entire address does not need to be provided for each read or write operation. For PIC18 devices, this is accomplished with a RAM banking scheme. This divides the memory space into 16 contiguous banks of 256 bytes. Depending on the instruction, each location can be addressed directly by its full 12-bit address, or an 8-bit low-order address and a 4-bit Bank Pointer" http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf Datenblatt zum PIC18F2455/2550/4455/4550
Gast
#2253963
Arc Net schrieb: > Der PIC18 hat unterschiedliche Bänke 1), wenn ich das auf die schnelle > richtig gelesen habe (TABLE 26-2), gibt's auch nur MOVFF um Bytes direkt > in den gesamten 4k umzukopieren, die restlichen Befehle arbeiten in/mit > der ausgewählten Bank. > Datenblatt zum PIC18F2455/2550/4455/4550 Eine sehr gute Bemerkung - vielen Dank dafür. Antwort schreiben |
Anzeige
|
