Welcome, Guest. Please login or register.


Author Topic: CoProcessor (Read 76905 times)

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: CoProcessor
« Reply #30 on: 2014.September.09. 23:39:45 »
It seems that some coprocessors manage BCD natively:

http://en.wikipedia.org/wiki/Intel_8087

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #31 on: 2014.September.10. 00:16:15 »
Quote from: gflorez
It seems that some coprocessors manage BCD natively:

http://en.wikipedia.org/wiki/Intel_8087

Maybe, but Am9511 is known at least to expand the Enterprise, I don't know about other existing solutions (hey, is there a real Am9511 for EP, or is it only a newspaper arcticle I've also read?). I guess FPUs for intel x86 family are too deeply bound to the x86 CPUs and can't be easily used with other CPUs like Z80 (but I can be wrong). I am also curious if there is some more modern solution for having an FPU other than the Am9511. uM-FPU is not so bad, but it's SPI based stuff.

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: CoProcessor
« Reply #32 on: 2014.September.10. 00:51:57 »
You are right, seems that a 8087  only acts as an extension of the 8086 or 8088 assembler set .

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #33 on: 2014.September.10. 07:11:35 »
Quote from: lgb
I'm curious if IS-BASIC can be modified somehow to use hardware coprocessor instead of software routines. But since IS-BASIC uses some kind of BCD logic (at least what I remember from my project to convert exos type-4 files into text or HTML on PC), I am not sure how easy/hard and efficient to do this ...
Yes, it would be an interesting project. I don't know anything about IS-BASIC number format, is it some kind of fixed point number?
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #34 on: 2014.September.10. 07:20:02 »
Quote from: lgb
Maybe, but Am9511 is known at least to expand the Enterprise, I don't know about other existing solutions (hey, is there a real Am9511 for EP, or is it only a newspaper arcticle I've also read?). I guess FPUs for intel x86 family are too deeply bound to the x86 CPUs and can't be easily used with other CPUs like Z80 (but I can be wrong). I am also curious if there is some more modern solution for having an FPU other than the Am9511. uM-FPU is not so bad, but it's SPI based stuff.
I've find a small  article about comparison of Amd and uM FPU-s, and it seems, on the same frequency the uM has similar speed as Amd.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, big advance of uM, it has IEEE 754 format (like the Am9512).
On the datasheet of Am9511 there is a speed comparison to software routines. A BASIC has the some floating point number format, like the Am9511, so it can be compare, and in average, the FPU is 50 times faster than software routines.

Találtam egy rövidke cikket, ami összehasonlítja (vagy inkább csak megemlíti) az AMD és a uM koprocit, és ez alapján úgy tűnik, azonos órajelen nagyjából azonos sebességűek.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, tudom, nagy előnye a uM-nak, hogy tudja az IEEE 754 formátumot, míg az Am9511 nem (csak az Am9512).
Az Am9511 adatlapján van egy teszt, ahol összehasonlítják a sebességét szoftveres rutinokkal (nagy szerencsére az egyik BASIC pont ugyanazt a lebegőpontos számformátumot használja, mint az AMD), és átlagban 50x gyorsabb a koproci. (2 perc helyett 2,5 mp alatt megrajzol egy Mandelbrot ábrát! :-))
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #35 on: 2014.September.10. 09:16:17 »
Quote from: Povi
Yes, it would be an interesting project. I don't know anything about IS-BASIC number format, is it some kind of fixed point number?

It's an interesting stuff, it's - if I remember correctly - packed BCD format (on hmmm maybe 5 bytes, so 10 digits) with an exponent byte. But I guess Bruce knows it much-much-much better :) http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #36 on: 2014.September.10. 10:10:01 »
A Pascal RTL rutinjait valahogy így kéne lecserélni:
Code: [Select]
;--------------------------
; X / Y Real
; input:
;   X in stack
;   Y in HLDE
; output:
;   X / Y in HLDE
;--------------------------
l0acd:  call convert2AMD        ; convert Y to AMD format and send it to AMD
        pop  bc                 ; get return address from top of the stack
        pop  de
        pop  hl                 ; HLDE = X
        push bc                 ; push return address
        call convert2AMD        ; convert X to AMD format and send it to AMD
        ld   a,019h             ; code for XCHF (exchange 32 bit operands)
        out  (CMDPORT),a
        ld   a,013h             ; code for FDIV
        out  (CMDPORT),a
        call error_handling
        jp   GetResult
Igen, tudom, hogy a rutinok igy csak a CMDPORT-ra kiküldött bájtban különböznek, az első hat sor minden kétoperandusos rutin elején azonos lenne, de mivel annyi hely van (jóval hosszabbak a szoftveres lebegőpontos rutinok), hogy a gyorsaság miatt maradhat igy (egy CALL / RET -tel kevesebb). XCHF is csak az osztásnál kell.
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #37 on: 2014.September.10. 10:14:43 »
a hibakezelő rutin pedig ez lenne:
Code: [Select]
error_handling:
        in   a,(CMDPORT)
        and  00011110b
        ret  z                  ; return if no error

        cp   00010000b
        jp   z,06b5h            ; Divide by zero

        cp   00001000b
        jp   z,06c4h            ; Maths call error

        cp   00011000b
        jp   z,06a1h            ; Number too large

        and  00000010b
        jp   nz,06a6h           ; Overflow

        ld   de,underflow_msg
        jp   0103h

underflow_msg:
        db   "Underflow",0

Az Underflow és Overflow hibánál a 3. és 4. bit állapota ismeretlen, ezért van AND a CP helyett.
*** Speicherplatz zu klein

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
Re: CoProcessor
« Reply #38 on: 2014.September.10. 10:33:24 »
Some other things than BASIC work too on BCD, for example the internal clock.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: CoProcessor
« Reply #39 on: 2014.September.10. 12:16:57 »
Quote from: lgb
It's an interesting stuff, it's - if I remember correctly - packed BCD format (on hmmm maybe 5 bytes, so 10 digits) with an exponent byte. But I guess Bruce knows it much-much-much better :) http://ep128.hu/Ep_Konyv/Gepi_kod_2.htm#342
If I recall correctly, it is 14 digits (7 bytes) BCD with an additional byte for the sign and exponent. Even without a co-processor, it could be possible to make it faster with IEEE-style 32-bit binary floats that are good enough for many of the BASIC programs, but the BCD format would ideally need to be replaced everywhere in the ROM.

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #40 on: 2014.September.10. 16:08:35 »
Azon gondolkodok, vajon az SADD (16 bites előjeles egész összeadás) utasítás vajon miért került bele a koprociba? Az adatlap szerint 16-18 órajel ciklus alatt fut le, miközben egy sima ADD HL,DE pedig csak 11 ciklus. És akkor még nem számoltam az adatok és a parancs kiküldésének az idejét...
*** Speicherplatz zu klein

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14710
  • Country: hu
    • http://enterprise.iko.hu/
Re: CoProcessor
« Reply #41 on: 2014.September.10. 16:13:51 »
Nem lehet, hogy olyan proci mellé szánták ami nem ismert ilyet?
Az adatokat mindig újra kell küldeni? Nem lehet előző számítás eredményével újabb műveletet végezni?

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #42 on: 2014.September.10. 16:41:16 »
Quote from: Zozosoft
Nem lehet, hogy olyan proci mellé szánták ami nem ismert ilyet?
Az adatokat mindig újra kell küldeni? Nem lehet előző számítás eredményével újabb műveletet végezni?
Nem tudom, milyen más proci lehetett a 70-es évek legvégén, ami nem tud összeadást... :-) (persze lehet, hogy én vagyok tudatlan).
De, lehet, az eredmény a verem tetején lesz. Aztán beküldök még egy operandust, aztán egy szorzást, és csak utána olvasom ki az eredményt. Azt is lehet, hogy előre betöltök a verembe 8 db integer-t, majd kiadok egymás után 7 darab összeadást, és utána olvasom csak ki az végeredményt. Igazából RPN módszerrel működik, ahogy nézem.
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #43 on: 2014.September.10. 18:21:22 »
Quote from: Povi
a hibakezelő rutin pedig ez lenne:

végül is rra-kkal is meg lehetne oldani, ha nem fontos, hogy a "Number too large" és a "Maths call error" meg legyen különböztetve... Rövidebb is, gyorsabb is.
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #44 on: 2014.September.11. 14:41:41 »
http://ep128.hu/Ep_Hardware/Pic/Rajz_Koopproci.gif
Az U5A és U5B invertereknek mi a célja?
Miért nem lehet közvetlenül összekötni a READY (PAUSE) kimenetet a Z80 WAIT bemenetével?
*** Speicherplatz zu klein