Bei 6502 Sprungbefehl zurück größer 256.

Naja, Du musst schon etwas geschickter programmieren.

Aber es geht doch relativ einfach, Beispiel (aus dem Gedächtnis, hatte 
seit ca. 20 Jahren keinen 65xx mehr unter den Fingern, abgesehen vom 
Nostalgiezocken auf dem C64):

Sagen wir das X-Register ist Dein Zähler.

ldx #$64                    ; Initialisiere Zähler

loop:
...
Großer Block mit vielen Anweisungen
...
dex                         ; dekrementiere Zähler
beq $1                      ; wenn 0, verlasse die Schleife
jmp loop                    ; noch ein Durchlauf

$1:
...Ende der Schleife

Statt dem X-Register kannst Du auch eine Speicherzelle nehmen, so kannst 
Du das X-Register in Deinem Block verwenden:

Am Anfang das ldx ersetzen durch:

lda #$64
sta $xxxx

Das dex ersetzen durch:

dec $xxxx

Dabei ist $xxxx die Speicherzelle für den Zähler.

Anstatt

1

BCC weit

einfach

1

BCS nah

2

JMP weit

3

nah:

Genau, entsprechend mit BNE / BEQ etc. Also man gibt die 
Abbruchbedingung an, und wenn diese nicht erfüllt ist, spring man mit 
einem absoluten "jmp" an den Anfang der Schleife.

Der Code muss aber dann natürlich an einer festen Position im Speicher 
stehen, aber ich glaube das war bei 6502 noch kein Problem ;-)

Der Offset bei den Branch Befehlen ist doch signed.
Also gehts nur -128 .. +127 Byte weit

Lothar schrieb:
> Zudem sieht man dass weil der erste ARM nur 64MB
> adressieren konnte alle späteren 32-Bit ARM immer noch das +/-32MB
> Sprung Limit haben.

Es ist schon schade, dass in 32 Bits nur 32 Bits passen. ;-)

Tatsächlich gibt es keinen inneren Zusammenhang zwischen dem 64 GB 
Programmadressraum der ersten ARMs und der +/-32 MB Sprungdistanz im 
Opcode. Das hat nichts miteinander zu tun. Der Adressraum kommt vom 
Layout des kombinierten PC+Statusregisters, die Sprungdistanz entstammt 
der davon völlig unabhängigen Befehlscodierung.

A. K. schrieb:
> Lothar schrieb:
>> Zudem sieht man dass weil der erste ARM nur 64MB
>> adressieren konnte alle späteren 32-Bit ARM immer noch das +/-32MB
>> Sprung Limit haben.
>
> Es ist schon schade, dass in 32 Bits nur 32 Bits passen. ;-)
>
>> Erst bei den 64-Bit ARM AArch64 wurde das abgeschafft.
>
> Yep, da sind nun immerhin stolze +/-32MB. Ok, mit Bedingung natürlich
> etwas weniger, also +/-1MB.

Wobei auch 1MB auch schon eine ziemlich lange Spagetti ist. 
Typischerweise findet man in so viel Code das ein oder andere "BL[X]? 
Rn", das sowieso immer nur zu Adressen springen kann, die in einem 
Register stehen.

ARM und 6502?  Ich finde da eher Ähnlichkeiten zu /370,
aber ok, die hatte nicht jeder zum probieren daheim stehen.
Ich auch nicht, aber durfte daran zumindest zum Geld verdienen 
rumspielen. ;-)

Carl D. schrieb:
> Wobei auch 1MB auch schon eine ziemlich lange Spagetti ist.

Für bedingte Sprünge ist das unnötig viel. Andererseits findet sich ein 
sehr ähnliches Befehlsformat bei diversen Load/Prefetch Rt, [PC+offset].

> ARM und 6502?

Es gibt einen historischen Zusammenhang, weil Acorn die ARM Architektur 
für die Ablösung der 6502 Rechner definierte.

Eine Ähnlichkeit gibt es indes: Bei beiden Architekturen entspricht das 
Carry-Flag nicht wie sonst üblich der Subtraktion, sondern der Addition 
des Einerkomplements, ist also bei Subtraktionsbefehlen invertiert.

A. K. schrieb:
> Carl D. schrieb:

>> ARM und 6502?
>
> Es gibt einen historischen Zusammenhang, weil Acorn die ARM Architektur
> für die Ablösung der 6502 Rechner definierte.

Ein großer Teil der ARM1-Entwicklung fand auch auf Acorns damaligem 
Flagschiff, einem auf zwei 6502 Prozessoren aufgerüsteten BBC Micro, 
statt. Für die ARM2-Entwicklung wurde der ARM1 als Zweitprozessor in den 
BBC Micro gesetzt; der ARM2 war der erste Prozessor, der in einem 
eigenständigen Rechner (dem Archimedes) eingesetzt wurde.

Die beiden Lead-Entwickler, Steve Furber und Sophie Wilson, hatten 
vorher an Acorn 6502 Systemen gearbeitet.

| They implemented [the ARM design] with a similar efficiency ethos as
| the 6502. A key design goal was achieving low-latency input/output
|(interrupt) handling like the 6502. The 6502's memory access
| architecture had let developers produce fast machines without costly
| direct memory access (DMA) hardware.

https://en.wikipedia.org/wiki/ARM_architecture#Acorn_RISC_Machine:_ARM2
(dort auch mit Quellen belegt)

georg schrieb:
> Meines Wissens gibt es auch
> keinen.

Dann erweitere bitte dein Wissen.

Die meisten Architekturen kennen "kurze" und "lange" Sprünge, wobei die 
bedingten Sprünge oft nur kurz sind. Falls du einen PC besitzt, schau 
dir mal den Befehlssatz der x86 Prozessoren an. Die kennen auch "near" 
und "far" Sprünge.

georg schrieb:
> Ein Prozessor, der nicht an jede Adresse in seinem Programm-Adressraum
> springen kann ist einfach nur unbrauchbar. Meines Wissens gibt es auch
> keinen.

Man kann es aber für den Programmierer auch umständlich machen, wenns 
genehm ist. National Semiconductors SC/MP kannte 2 Arten von Sprüngen:
  8-Bit relativ zu 4 Adressregistern, darunter dem PC
  Exchange vom PC mit einem dieser 16-Bit Adressregister

Ein solches Adressregister wurde natürlich nicht direkt geladen:
  load accu immediate
  exchange with Px low
  load accu immediate
  exchange with Px high

Eine direkte Adressierung im Befehl gab es nicht. Ein RISC wars auch 
nicht, also an fehlendem Opcode-Space (wie bei ARM) lag es nicht.

Es gab weder einen internen oder externen Stack, noch einen 
Unterprogrammaufruf jenseits dieser Exchange-PC Befehle. Wenn man 
partout Interrupts haben wollte, dann war Adressregister P3 weg, als 
Vektor und Rückkehradresse (Exchange PC mit P3).

Georg G. schrieb:
> georg schrieb:
>> Meines Wissens gibt es auch
>> keinen.
>
> Dann erweitere bitte dein Wissen.

Und du solltest sinnentnehmendes Lesen üben.

> Die meisten Architekturen kennen "kurze" und "lange" Sprünge

Ach was. Kannst du mal zeigen, wo
dein Vorposter etwas anderes behauptet?

georg schrieb:
> Ein Prozessor, der nicht an jede Adresse in seinem Programm-Adressraum
> springen kann ist einfach nur unbrauchbar. Meines Wissens gibt es auch
> keinen.

TriCore?

Ist zwar nicht so verbreitet, aber immerhin in KFZ-Motorsteuergeräten 
eingesetzt — und sooo viele Hersteller von den Dingern gibt's nicht.

Eine Möglichkeit, überweite Sprünge zu behandeln, ist per Tools.  Weil 
der Compiler die Offsets nicht kennt (zumindest den zu anderen 
Funktionen) kann der Linker gegebenenfalls einen indirekten Sprung / 
Call einfügen.  Dazu braucht man ein Call-Clobbered Register, das nicht 
zur Parameterübergabe dienen kann, und das ist im Falle der TriCore EABI 
gegeben.

georg schrieb:
> Meines Wissens gibt es auch
> keinen.

Ich habe aber noch einen - die 8-Bit Prozessoren der Weltfirma Elan, die 
mir ab und zu in Wechselrichtern unterkommen. Ein absolutes JMP kann nur 
innerhalb der 1k Page springen, wobei z.B. der EM78P458 vier Pages hat. 
Aber diese MC möchte man i.A. sowieso nicht programmieren.

Ich würde noch den Motorola MC14500B in die Runde werfen. Da der 
Programmzähler nicht Teil des Prozessors ist, hängt die Frage, ob und 
wie man überhaupt springen kann, von der Außenbeschaltung ab.