---

Hej alle

Vi (projekt gruppe) har et problem i vores programmering af
operativsystem systemkald (software interrupt).

Compiler: Borland C++ 1.01
Ingen standard-header's bruges!


Problemet består i, at vi skal have en lokalvariabel i en
interrupt-procedure, det er også fint nok, men når vi går ind i selve
interrupt-rutinen får vi flg. asm-kode:

_systemCall   proc   far
   push   ax
   push   bx
   push   cx
   push   dx
   push   es
   push   ds
   push   si
   push   di
   push   bp
   mov   bp,DGROUP
   mov   ds,bp
   mov   bp,sp
   sub   sp,24

Dvs.
DS = DGROUP <-- operativsystemets data-segment
BP = SP <-- user-processens stack-pointer

Men når lokale variable tilgås anvendes BP-pointeren jo selvfølgelig til
formålet, men desværre har vi jo lige skiftet DS ud til
operativsystemets pointer og nu vil adressen

DS*16 + BP + offset

blive anvendt som lokal variabel! Dvs. nu befinder vi os jo ikke længere
i datasegmentet/stacksegmentet for user-processen, men derimod i
operativsystemets data-område hvor globale variable ligger.

f.eks.

;    d = outregs->dx;
;   
   mov   ax,word ptr [di+6]
   mov   word ptr [bp-8],ax


Dette er ikke særlig smart da ethvert systemkald så vil lave rav i
variablene (og ja, vi er stødt ind i problemet)!

Værre er så, at vi faktisk ændrer AX, BX, CX og DX registrene ved udgang
af interruptet - mærkeligt nok returnerer disse værdier godt nok når vi
anvender flg. asm-kode:


;    asm {
;    mov ax,a;
;   
   mov    ax,[bp-2]
;   
;    mov bx,b;
;   
   mov    bx,[bp-4]
;   
;    mov cx,c;
;   
   mov    cx,[bp-6]
;   
;    mov dx,d;
;   
   mov    dx,[bp-8]
;   
;    mov [BP+16],ax;
;   
   mov    [BP+16],ax
;   
;    mov [BP+14],bx;
;   
   mov    [BP+14],bx
;   
;    mov [BP+12],cx;
;   
   mov    [BP+12],cx
;   
;    mov [BP+10],dx;
;   
   mov    [BP+10],dx
;   
;    }
;   
;   }
;   
   leave   
   pop   di
   pop   si
   pop   ds
   pop   es
   pop   dx
   pop   cx
   pop   bx
   pop   ax
   iret


Nogen der kan forklare hvordan vi skal lave programmet anderledes for at
vi kan anvende variable (lokale) i interrupt-routinen uden at den laver
rav i data-segmentet på operativsystemet!

Og hvorfor returnerer værdierne i registrene egentlig korrekt alligevel
- det forstår jeg slet ikke!

Noget er rigtigt, men et memory-dump viste os i hvert fald at antagelse
med at interruptet overskriver noget af memory giver os store problemer!


Håber på alt den hjælp i kan give

Postet i både dk.teknik.elektronik og dk.edb.programmering.c, da dette
har nær relevans for begge grupper i henhold til at ovenstående bruges
meget til embeddede løsninger!


Mvh / Preben


P.S. Skriv hvis i mangler noget information! Skal være til en fødselsdag
om en halv time så det er skrevet lidt hurtigt!

P.P.S. QuintOS.dk (dvs. indtil videre ligger siden på myservice.dk)
fortæller lidt om projektet, men desværre er den ikke så udviklet endnu,
men det kommer nok en dag!

---

Jeg har lige kigget lidt i et gammelt projekt, jeg have glemt noget, jeg har
ikke roddet med x86 siden...

Preben Holm wrote:

> ... DS*16 + BP + offset

>
> blive anvendt som lokal variabel! Dvs. nu befinder vi os jo ikke længere
> i datasegmentet/stacksegmentet for user-processen, men derimod i
> operativsystemets data-område hvor globale variable ligger.
>

Det er jo også normalt det man vil, interruptet sørger for at alt er som
før...

Hvis i vil have fat i processens dataområde, så er det jo bare at simulere
'leave' ... det er vist noget med SP=BP og pop BP.

Husk at parkere SP til startværdien igen, ellers bliver det nok noget rod
når i går ud af rutinen 8)

Men det kan godt være jeg har glemt noget...

Mvh
Kimjand

---

Kim Johan Andersson wrote:

> Det er jo også normalt det man vil, interruptet sørger for at alt er som
> før...
>

Forresten, det er normalt at pass'e parametre til interrupts gennem
cpu-registre... dem kan du jo bare snuppe oppe fra stakken. Hvis du ændrer dem
på stakken bliver de jo spolet tilbage i registrene ved udgang af rutinen.

Mvh
Kimjand

---

Hej


>>... DS*16 + BP + offset
>
>>blive anvendt som lokal variabel! Dvs. nu befinder vi os jo ikke længere
>>i datasegmentet/stacksegmentet for user-processen, men derimod i
>>operativsystemets data-område hvor globale variable ligger.
>>
>
>
> Det er jo også normalt det man vil, interruptet sørger for at alt er som
> før...

Ja, men det er netop det der er problemet. Interruptets lokal-variable
overskriver global-variable i OS'ets DS, og det er et stort problem for os.
Det er jo netop fordi den nupper jo netop user-processens stackpointer
men propper den ned i OS'ets datasegment, og det er jo en gang bæ!

Well, vi vil jo gerne have mulighed for at ændre variable i
styresystemet (helst uden brug af far-pointere), men også uden at fuske
for meget!


> Hvis i vil have fat i processens dataområde, så er det jo bare at simulere
> 'leave' ... det er vist noget med SP=BP og pop BP.

Hmm, ja, men det er bare lidt noget rod, for C-compilere gør jo en masse
mere helt af sig selv, og så er der jo væsentligt mere der skal pop'es
og det kan give en masse rod!


> Husk at parkere SP til startværdien igen, ellers bliver det nok noget rod
> når i går ud af rutinen 8)

Tak for hjælpen, vil overveje hvad der er bedst, men skriv endelig hvis
du/I finder på noget smart


Mvh / Preben

---

Preben Holm wrote:
> Men når lokale variable tilgås anvendes BP-pointeren jo selvfølgelig til
> formålet, men desværre har vi jo lige skiftet DS ud til
> operativsystemets pointer og nu vil adressen
>
> DS*16 + BP + offset

Jeg tror der er noget i har misforstået. Som default anvendes
stacksegmentet (SS) i forbindelse med stack pointer (SP) og base pointer
(BP).

Det vil sige at for instruktionen
mov ax, [bp-2]
vil den fysiske adresse for den lokale variabel bliver udregnet som
SS*16+BP-2. Hvis man rent faktisk ønsker at bruge datasegmentet (DS)
skrives:
mov ax, ds:[bp-2]

Det samme kan også gøres med CS og ES.

Jeres brug af lokale variabler ser derfor fornuftig nok ud, og jeg kan
ikke se at det skulle overskrive noget forkert. Men det kan være fordi i
bruger et andet register som i tror også henviser til stacken. Alle
andre registre bruger DS som default, bort set fra DI som bruger ES som
default.

Ivan Johansen

---

Hej Preben,


> Vi (projekt gruppe) har et problem i vores programmering af
> operativsystem systemkald (software interrupt).
>
> Compiler: Borland C++ 1.01

Gosh, bruges den stadig ? ;)


> Problemet består i, at vi skal have en lokalvariabel i en
> interrupt-procedure, [...]
>
> Nogen der kan forklare hvordan vi skal lave programmet anderledes for at
> vi kan anvende variable (lokale) i interrupt-routinen uden at den laver
> rav i data-segmentet på operativsystemet!

En prædefineret chunk afsat til en ekstra stack der så switches med kunne
være en løsning... Men "alting" er lettere når man skriver helt nede på
jernet og det er _alt_ for mange år siden, at Borlands C++ ver. 1. blev
smidt ud af min maskine til at jeg tør anvise en præcis metode. (Hvad med
at patche den kompilerede kode i debug ;)


> Og hvorfor returnerer værdierne i registrene egentlig korrekt alligevel
> - det forstår jeg slet ikke!

Magic ;)


> P.S. Skriv hvis i mangler noget information!

Jo tak, hører da gerne lottoresultaterne for de næste par uger :P


--
Venlig hilsen,
Søren
* If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b <http://www.ElektronikTeknolog.dk/cgi-bin/LM317/>

---

Hej igen

>>Compiler: Borland C++ 1.01
>
>
> Gosh, bruges den stadig ? ;)

Ja da - den er jo gratis nu om dage

Og sammen med en tasm 1.01 kører skidtet sq godt nok *s* (den er dog
ikke ligefrem gratis selvom den godt kunne være det *gg*)



>>Problemet består i, at vi skal have en lokalvariabel i en
>>interrupt-procedure, [...]
>>
>>Nogen der kan forklare hvordan vi skal lave programmet anderledes for at
>>vi kan anvende variable (lokale) i interrupt-routinen uden at den laver
>>rav i data-segmentet på operativsystemet!
>
>
> En prædefineret chunk afsat til en ekstra stack der så switches med kunne
> være en løsning... Men "alting" er lettere når man skriver helt nede på
> jernet og det er _alt_ for mange år siden, at Borlands C++ ver. 1. blev
> smidt ud af min maskine til at jeg tør anvise en præcis metode. (Hvad med
> at patche den kompilerede kode i debug ;)

Well, jeg synes vi ændrer for meget på koden hele tiden til at patching
vil være en fornuftig løsning, men en specifik stack til interrupt's
kunne måske være en løsning - synes bare det er lidt underligt, at
compileren fucker op i interruptets lokal-variable - mærkeligt at der er
ikke er fundet noget smart der - specielt når den automatisk sørger for
skift af data-segment, så virker det nu noget mærkeligere!


>>Og hvorfor returnerer værdierne i registrene egentlig korrekt alligevel
>>- det forstår jeg slet ikke!
>
> Magic ;)

Hehe, ja, det må det være, for det giver ikke meget mening!


>>P.S. Skriv hvis i mangler noget information!
>
>
> Jo tak, hører da gerne lottoresultaterne for de næste par uger :P

7,9,14,15,18,24,32

Og hvis det er vindertallene for næste uges lotto, kunne det godt ske
jeg blev MEGET negativ over ikke at have spillet *hehe*

---

Hej Preben,


> Ja da - den er jo gratis nu om dage

Der er i hvert fald ingen der vil betale for den ;)


> Og sammen med en tasm 1.01 kører skidtet sq godt nok *s* (den er dog
> ikke ligefrem gratis selvom den godt kunne være det *gg*)

I har da rigtig gang i antikviteterne ;)
Hvorfor ikke bruge MASM så, den _er_ vist gratis (i nogle versioner) ?
Eller en af open source assemblerne ?


> Well, jeg synes vi ændrer for meget på koden hele tiden til at
> patching vil være en fornuftig løsning,

Det var nu heller ikke ment alvorligt.


> men en specifik stack til
> interrupt's kunne måske være en løsning - synes bare det er lidt
> underligt, at compileren fucker op i interruptets lokal-variable -
> mærkeligt at der er ikke er fundet noget smart der - specielt når den
> automatisk sørger for skift af data-segment, så virker det nu noget
> mærkeligere!

Tjaa, måske en "feature" - Ver.1 blev jo heller ikke Den Endelige Lløsning
;P


> 7,9,14,15,18,24,32
>
> Og hvis det er vindertallene for næste uges lotto, kunne det godt ske
> jeg blev MEGET negativ over ikke at have spillet *hehe*

Mee too, for jeg er alt for meget skeptiker til at spille, endda så meget
at jeg tager mig til hovedet når kæresten af og til hiver et skrabelod
frem (men OK, de har vist ikke sandsynlighedsregning på humanoira ;)


--
Venlig hilsen,
Søren
* If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b <http://www.ElektronikTeknolog.dk/cgi-bin/LM317/>

---

>Der er i hvert fald ingen der vil
>betale for den ;)
Nej, det er da rigtigt nok!

>> Og sammen med en tasm 1.01 kører
>>skidtet sq godt nok *s* (den er dog
>> ikke ligefrem gratis selvom den
>>godt kunne være det *gg*)
>
>I har da rigtig gang i antikviteterne ;)
>Hvorfor ikke bruge MASM så, den _er_
>vist gratis (i nogle versioner) ?
>Eller en af open source assemblerne ?

Tja, vi skulle i så tilfælde omdøbe filen til tasm for ellers tror
jeg
ikke borland c++ 1.01 vil arbejde sammen med den - men det kan da
godt
være det vil virke? Eller kan man indstille det til sin egen
assembler
på nogen måde?


>> men en specifik stack til
>> interrupt´s kunne måske være en
>>løsning - synes bare det er lidt
>> underligt, at compileren fucker op
>>i interruptets lokal-variable -
>> mærkeligt at der er ikke er fundet
>>noget smart der - specielt når den
>> automatisk sørger for skift af
>>data-segment, så virker det nu noget
>> mærkeligere!
>
>Tjaa, måske en "feature" - Ver.1 blev
>jo heller ikke Den Endelige Lløsning
>;P



>> 7,9,14,15,18,24,32
>>
>> Og hvis det er vindertallene for
>>næste uges lotto, kunne det godt ske
>> jeg blev MEGET negativ over ikke at
>>have spillet *hehe*
>
>Mee too, for jeg er alt for meget
>skeptiker til at spille, endda så meget
>at jeg tager mig til hovedet når
>kæresten af og til hiver et skrabelod
>frem (men OK, de har vist ikke
>sandsynlighedsregning på humanoira ;)

Næh, det er jo ikke ligefrem det der præger dem derude *gg*

Heldigvis er SDU opdelt (groft sagt) i to afdelinger - humaniora og
naturvidenskabelige uddannelser - og det er det jo mere eller mindre
også fysisk: humaniora mod nord og naturvidenskab mod syd *gg*


Mvh / Preben

---

Hej Preben,


> Tja, vi skulle i så tilfælde omdøbe filen til tasm for ellers tror
> jeg
> ikke borland c++ 1.01 vil arbejde sammen med den - men det kan da
> godt
> være det vil virke? Eller kan man indstille det til sin egen
> assembler
> på nogen måde?

Det har jeg aldrig leget med (skidt for sig og snot for sig), men jeg
kunne forestille mig at det ikke lader sig gøre alt for let (om
overhovedet).


> Næh, det er jo ikke ligefrem det der præger dem derude *gg*

Nej, men heldigvis har de andre gode egenskaber at leve på :)


> Heldigvis er SDU opdelt (groft sagt) i to afdelinger - humaniora og
> naturvidenskabelige uddannelser - og det er det jo mere eller mindre
> også fysisk: humaniora mod nord og naturvidenskab mod syd *gg*

Heldigvis ?
Det er da på humanoira at alle sildene flokkes ;)


--
Venlig hilsen,
Søren
* If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b <http://www.ElektronikTeknolog.dk/cgi-bin/LM317/>

---

> Det har jeg aldrig leget med (skidt for sig og snot for sig), men jeg
> kunne forestille mig at det ikke lader sig gøre alt for let (om
> overhovedet).

Næh, men det kunne selvfølgelig være lidt sjovt alligevel *gg*


>>Næh, det er jo ikke ligefrem det der præger dem derude *gg*
>
>
> Nej, men heldigvis har de andre gode egenskaber at leve på :)

Jep! Nogle af dem i hvert fald *gg*


>>Heldigvis er SDU opdelt (groft sagt) i to afdelinger - humaniora og
>>naturvidenskabelige uddannelser - og det er det jo mere eller mindre
>>også fysisk: humaniora mod nord og naturvidenskab mod syd *gg*
>
>
> Heldigvis ?
> Det er da på humanoira at alle sildene flokkes ;)

Tjaaa, men medicinerne/biologerne er nu heller ikke ligefrem værst, hvis
jeg nu skal give min ærlige mening til kende!
Mange humaniora'er er da godt nok ikke altid lige helt normale - eller
dvs. man ved jo ikke om de normale humaniora'er er det ene eller det
andet - de afviger jo ikke *gg*!

---

Hej Preben,


> Tjaaa, men medicinerne/biologerne er nu heller ikke ligefrem værst,
> hvis jeg nu skal give min ærlige mening til kende!

Især hvis man vil lege doktor ;) og de burde da have lært
sandsynlighedsregning.


> Mange humaniora'er er da godt nok ikke altid lige helt normale -
> eller dvs. man ved jo ikke om de normale humaniora'er er det ene
> eller det andet - de afviger jo ikke *gg*!

Hmmm, det unormale er nu også mere underholdene at observere :)


--
Venlig hilsen,
Søren
* If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b <http://www.ElektronikTeknolog.dk/cgi-bin/LM317/>