C questions - Hardware access & usage of Super()

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 3:04 pm

I am working on a low level lib and I recently changed some code about switching to supervisor mode.
My understanding of the GEMDOS call Super() is the following:
Super(1) return 0 if in user mode -1 if in supervisor mode.
Super(0) put you in supervisor mode and return the ssp that you must keep to get back to user mode and
Super(ssp) with the value saved above return you in User mode.

Here is an extract from hitchhiker's guide on Super
Hack processor privilege mode. If stack is 1L, return 0 or -1 (processor is in user or supervisor mode). If in user mode, switch to supervisor mode and use stack as the supervisor stack (or the value from USP if stack is NULL). If in supervisor mode, switch to user mode and use stack as the supervisor stack. Return the old supervisor stack value.


If I use one call to go in supervisor mode at begining of program, do everything including HD stuff, and do one call to get back to user mode everything seems OK.

Now if I use 2 Super() calls (one to get in and one to get out) each time I need to access HW in a subroutine, it crashes (range from bus error to ??? 2 or 4 bombs) - mostly with Lattice C.

Here is an example of code:

Code: Select all

#include <stdio.h>

#if defined (__PUREC__)            /* We compile with Pure C */
#include <tos.h>
#elif defined(ATARI)            /* We compile with Lattice C */
#include <osbind.h>
#endif
long   ssp = 0;

/*
Definition in Pure C
long    Super( void *stack );

Definition in Lattice C
#define Super(a)      __pgp(0x20,a)
void *__pgp(int,void *);
*/

void senter(void) {
   ssp = (long)Super((void*)0);         /* enter supervisor mode */
}

void sexit(void) {
   ssp = (long)Super((void*)ssp);         /* return processor to user mode */
}

int main(int argc, char* argv[]) {
   long mode;
   
   mode = (long)Super((void*)1L);
   fprintf(stdout, "We are in %s mode\n", mode ? "Supervisor" : "User");

   ssp = (long)Super((void*)0);         /* enter supervisor mode */
   mode = (long)Super((void*)1L);
   fprintf(stdout, "We are in %s mode ssp=%lx\n", mode ? "Supervisor" : "User", ssp);

   ssp = (long)Super((void*)ssp);         /* return processor to user mode */
   mode = (long)Super((void*)1L);
   fprintf(stdout, "We are in %s mode ssp=%lx\n", mode ? "Supervisor" : "User", ssp);

   senter();
   mode = (long)Super((void*)1L);
   fprintf(stdout, "We are in %s mode ssp=%lx\n", mode ? "Supervisor" : "User", ssp);

   sexit();
   mode = (long)Super((void*)1L);
   fprintf(stdout, "We are in %s mode ssp=%lx\n", mode ? "Supervisor" : "User", ssp);

   return 0;
}


This small program does not crash but :
- it display a value for SSP that looks strange to me $37CA
- it display exactly the same stack value when compiled with Lattice and Pure C ?
- Sometimes compiler crash after running this nice program ???

Can someone tell what I am doing wrong ??? PS I do not want to use supexec()

Attached a zip file with super.c suppc.prj suppc.tos (project file for Pure C and exec) suplc.prj suplc.tos (project for Lattice C and exec)
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Mon Oct 06, 2008 12:54 pm, edited 2 times in total.

User avatar
Klapauzius
The Klaz
The Klaz
Posts: 4302
Joined: Sun Jul 04, 2004 7:55 am
Location: Bavaria
Contact:

Re: C questions - Hardware access & usage of Super()

Postby Klapauzius » Fri Oct 03, 2008 3:19 pm

DrCoolZic wrote:This small program does not crash but :
- it display a value for SSP that looks strange to me $37CA
- it display exactly the same stack value when compiled with Lattice and Pure C ?


I don't know much (anything? ;-) ) about C, but the SSP location $37ca is ok: it's TOS'/GEMs SSP which resides in low mem (below the TPA).
You will always get the same value (or at least values close to each other) regardless of compiler/language/etc. because what you see is not the SSP address of your own program but the address where the SSP was before your application entered supervisor mode.
http://www.klapauzius.net
http://dbug.kicks-ass.net/klaz

The tears are welling in my eyes again, I need twenty big buckets to catch them in, twenty pretty girls to carry them down, twenty deep holes to bury them in.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5006
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: C questions - Hardware access & usage of Super()

Postby simonsunnyboy » Fri Oct 03, 2008 3:35 pm

If you just don't want to mess with the stack but just call a method/function in Supervisor mode, use Supexec() from XBIOS.
It's easy to use and IIRC we already discussed that for Pure C.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 3:44 pm

simonsunnyboy wrote:If you just don't want to mess with the stack but just call a method/function in Supervisor mode, use Supexec() from XBIOS.
It's easy to use and IIRC we already discussed that for Pure C.
I do not like too much this solution because once I enter some part of my program it is not just few calls that access HW but a lot of calls
scattered. This is why I did not bother originally just enter supervisor at start of program and leaves at the end. However now I am adding some GEM calls and from what I understand Super and GEM do not like each other!

belboz
Captain Atari
Captain Atari
Posts: 164
Joined: Sat Aug 23, 2003 9:50 pm

Re: C questions - Hardware access & usage of Super()

Postby belboz » Fri Oct 03, 2008 3:55 pm

I don't use Pure C, but when it comes to Lattice you should be able to do just something like this. This is ripped right from some of my code. Obviously cut up to just do the supervisor stuff.

I don't know why your doing the #define in your lattice code for Super() since it is all ready taken care of by osbind.h

Code: Select all

#include<osbind.h>

void *save;

main()
{
  save=Super(0L);
 /* Do your Supervisor related stuff */
  Super(save);
}

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 4:07 pm

belboz wrote:I don't use Pure C, but when it comes to Lattice you should be able to do just something like this. This is ripped right from some of my code. Obviously cut up to just do the supervisor stuff.
If you look at the code this is just what I am doing. And it seems to work fine when called from main() but if called from within a subroutine (actually about 2 calls down from main) it breaks.
Is it because at this time the stack is already used bu my calls ??? And it is not always not working or if you prefer it is sometimes working !!!

I don't know what your doing the #define in lattice for Super() since it is all ready taken care of by osbind.h

If you look at my example you will see that this information is commented. I am just showing that unfortunately the declaration in Lattice and in Pure C are different and that if we want to compile on both without warnings we need to do some casting. But fortunately long and void* are 32 bits on both compiler so casting should be safe.

User avatar
Klapauzius
The Klaz
The Klaz
Posts: 4302
Joined: Sun Jul 04, 2004 7:55 am
Location: Bavaria
Contact:

Re: C questions - Hardware access & usage of Super()

Postby Klapauzius » Fri Oct 03, 2008 4:16 pm

DrCoolZic wrote:If you look at the code this is just what I am doing. And it seems to work fine when called from main() but if called from within a subroutine (actually about 2 calls down from main) it breaks.
Is it because at this time the stack is already used bu my calls ??? And it is not always not working or if you prefer it is sometimes working !!!


That's because TOS will return your old USP once you leave supervisor mode.
Now, if you're down one or more subroutines in relation to what you were when you entered supervisor mode, and return to user mode (via TOS) this will (most likely) crash your program, beacuse the contents on the USP are not valid anymore.
I'd do both Super calls from main() - you should be fine then. :-)
http://www.klapauzius.net
http://dbug.kicks-ass.net/klaz

The tears are welling in my eyes again, I need twenty big buckets to catch them in, twenty pretty girls to carry them down, twenty deep holes to bury them in.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 4:23 pm

something went wrong here - deleted post
Last edited by DrCoolZic on Fri Oct 03, 2008 5:47 pm, edited 1 time in total.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5006
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: C questions - Hardware access & usage of Super()

Postby simonsunnyboy » Fri Oct 03, 2008 4:28 pm

Well for demo coding, I would simply coder a main() which simply does Supexec() on my_main() :D
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 4:34 pm

I would like to understand what I am doing wrong? Super() should not be more difficult than supexec() ? And what is strange is that the program runs fine when compiled with Pure C.
I still have the problem of not having documentation on Lattice C and may be I have set some compilation flags wrong ???

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 5:56 pm

Klapauzius wrote: Now, if you're down one or more subroutines in relation to what you were when you entered supervisor mode, and return to user mode (via TOS) this will (most likely) crash your program, beacuse the contents on the USP are not valid anymore.
I'd do both Super calls from main() - you should be fine then. :-)

This is very interesting If I understand correctly what is important is to enter and return to/from supervisor mode at the "same level" for example main as
you suggest, but probably should work at any level.
So is a prog like this a problem:

Code: Select all

enter() {
    ssp = Super(0L);
}
leaves () {
    Super(ssp);
}
sub() {
    enter();
    /* HW stuff */
    leaves();
}
main() {
    sub();
}

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Fri Oct 03, 2008 8:48 pm

simonsunnyboy wrote:Well for demo coding, I would simply coder a main() which simply does Supexec() on my_main() :D

I have looked at Supexec(). It is declared as supexec(long(*func)()). If I interpret correctly the argument is a pointer to a function taking no argument and returning a long?
If this is the case then it is a problem as all my "HW functions" takes a large number of arguments!
I inverstigated more doing the enter and leave to/from super in the same routines and apparently executing the return from super mode works fine. But when this routine returns to the calling one it bombs and this seems to indicate that the stack got not restored to previous state or corrupted ??? Again works fine with Pure C

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5006
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: C questions - Hardware access & usage of Super()

Postby simonsunnyboy » Sat Oct 04, 2008 3:16 pm

Ehem, looking at your calls, you do nest set super etc into subroutines?
You do realize that calling and leaving a function/subroutine alters the stack pointer?
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Mon Oct 06, 2008 10:15 am

simonsunnyboy wrote:Ehem, looking at your calls, you do nest set super etc into subroutines?
You do realize that calling and leaving a function/subroutine alters the stack pointer?
Yes I do ! Hovever returning from subroutine should restore the stack ? Rignt ?
OK lets step back a liitle bit.
Here is my understanding of going into supervisor mode (can someone correct me if I am wrong):
68K has two stacks (i.e. 2 reg A7). In user mode the processor uses user a7 (shown as a7 in devpac monst) and in svm it uses another a7 (a7' in monst 2 and ssp in monst 3) ?
When you jump to a subroutine the return address and eventually parameters are pushed on a stack and when return the pc addres is restored from stack and stack value get adjusted.

Using Super(0) pushes 0 and 20 (gemdos Super() number call) and call trap 1. After exec the ssp now contains old a7 value (due to Super() called with 0 param?) and the S bit of processeur is set.
You have to save the value retruned (in D0) as this is the previous value of SSP that will need to be restored and you continue the execution but now you are using ssp instaed of a7.
So calling a subroutine will now push address to ssp ... You do your HW stuff by calling subroutines and hopefully when you return from them now the stack (ssp) should have same value as when you returned from trap 1. Now you call again Super(ssp) with the value saved this should now put back the original value of SSP into ssp and you should now use a7 as the stack and therefore you should be in same "state" as before you did the first super call ?
I did a strip down to minimum version of my program run it and it works fine !?! Then I added a printf debug statement and boom it bombs ?????????
This indicates something wrong it sometimes works sometimes does not ???
I compiled with full debug remove stack checking and went under monst.
I t seems that when returning from supervisor mode the stack is not reset to proper value it adjust the a7 with a value too big ???
and next time you call something then the return value get overwritten with garbage and ... it crashes
attached is the source the full debug executable that you can load under monst or latttice c debug
and the working pure c
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Mon Oct 06, 2008 11:59 am

It really seems that it is the Lattice C compiler that is wrong. I am not familiar with 68K assembly but the generated code look wrong:

Code: Select all


_fdc_get_reg   
   movem.l   d6-d7/a5,-(a7)
   move.w   $12(a7),d7
   movea.l   #$FF8606,a5
   move.w   d7,(a5)
   subq.w   #2,a5
   move.w   (a5),d6
   move.l   d6,d0
   movem.l   (a7)+,d6-d7/a5
   rts
_fd_save   
   movem.l   d2/a2,-(a7)
   pea   $654(a4)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   addq.w   #6,a7
   move.l   d0,_ssp(a4)
   move.l   d0,-(a7)
   pea   4(a4)
   pea   $176(a4)
   jsr   $B0B50(pc)
   movea.w   #$43E,a0
   move.w   #1,(a0)
   pea   $82.w
   bsr.s   _fdc_get_reg
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,_track(a4)
   pea   $84.w
   bsr.s   _fdc_get_reg
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,_sector(a4)
   movea.w   #$43E,a0
   clr.w   (a0)
   movea.l   _ssp(a4),a0
   move.l   a0,(a7)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   lea   $16(a7),a7
   move.l   d0,_ssp(a4)
   move.l   d0,-(a7)
   pea   $26(a4)
   pea   $176(a4)
   jsr   $B0B50(pc)
   lea   $C(a7),a7
   movem.l   (a7)+,d2/a2
   rts
_main   
   link   a6,#0
   bsr.s   _fd_save
   moveq   #0,d0
   unlk   a6
   rts

So the first trap #1 is followed by an addq.w #6, a7 which seems ok but the second is followed by an lea $16(a7),a7 and this looks wrong ?
Pure C call a subroutine called Super!

Code: Select all

    pea.l     (a2)
    pea.l     (a0)
    move.w #$20,-(a7)
    trap      #1
    addq.w #6,a7
    movea.l (a7)+,a2
    rts

and this seems to work fine.
I guess that Lattice is trying to be smart and ajust the SP for several call at same time, not knowing that in between it is not acting on the same stack pointer ! (changed from ssp to usp)
So I looked at compiler options and found under Options->Compiler->Objects "Disable Stack Merging" which seems related to my problem. So I checked it and now each Trap is followed by an add.w #6, a7:

Code: Select all

_fd_save   movem.l   d2/a2,-(a7)
   pea   $654(a4)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   addq.w   #6,a7
   move.l   d0,0(a4)
   move.l   d0,-(a7)
   pea   4(a4)
   pea   $176(a4)
   jsr   $B0B5C(pc)
   lea   $C(a7),a7
   movea.w   #$43E,a0
   move.w   #1,(a0)
   pea   $82.w
   bsr.s   _fdc_get_reg
   addq.w   #4,a7
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,$264(a4)
   pea   $84.w
   bsr.s   _fdc_get_reg
   addq.w   #4,a7
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,$268(a4)
   movea.w   #$43E,a0
   clr.w   (a0)
   movea.l   0(a4),a0
   move.l   a0,-(a7)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   addq.w   #6,a7
   move.l   d0,0(a4)
   move.l   d0,-(a7)
   pea   $26(a4)
   pea   $176(a4)
   jsr   $B0B5C(pc)
   lea   $C(a7),a7
   movem.l   (a7)+,d2/a2
   rts
However does not seems better ?!?
Well actually it is better the stack is now off by 4 bytes instead of about 10 bytes !!!! Let see if we can find some other flags!

Note in this version I have replaced the Super(0L) call by:

Code: Select all

char stack[1024]
ssp = Super(&stack[1000]);
Where 1000 is smaller than 1024 so that the incorrect bumping of stack restauration does not pass over ....

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Mon Oct 06, 2008 12:34 pm

OK It looks like I solved the Problem.
If I use the flag options->compiler->objects "alaways generate stack frames" then it works !!!!
But if you remove the "disable stack merging" it crashes again. Therefore You must use both options during compilation.

Now the code look like this:

Code: Select all

_fd_save   
   link   a6,#-2
   movem.l   d2/a2,-(a7)
   clr.l   -(a7)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   addq.w   #6,a7
   move.l   d0,_ssp(a4)
   move.l   d0,-(a7)
   pea   4(a4)
   pea   $176(a4)
   jsr   $B0B58(pc)
   lea   $C(a7),a7
   movea.w   #$43E,a0
   move.w   #1,(a0)
   pea   $82.w
   bsr.s   _fdc_get_reg
   addq.w   #4,a7
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,_track(a4)
   pea   $84.w
   bsr.s   _fdc_get_reg
   addq.w   #4,a7
   moveq   #0,d1
   move.b   d0,d1
   move.l   d1,_sector(a4)
   movea.w   #$43E,a0
   clr.w   (a0)
   movea.l   _ssp(a4),a0
   move.l   a0,-(a7)
   moveq   #$20,d0
   move.w   d0,-(a7)
   trap   #1
   addq.w   #6,a7
   move.l   d0,_ssp(a4)
   move.l   d0,-(a7)
   pea   $26(a4)
   pea   $176(a4)
   jsr   $B0B58(pc)
   lea   $C(a7),a7
   movem.l   (a7)+,d2/a2
   unlk   a6
   rts


But this not satisfying for the mind ?!!!? I am still wandering if I am doing something wrong. I can't beleive Lattice C would make such mistake ????

By the way not directly related but ... Does someone now how to turn off all interrupts (critical section) directly from C ?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: C questions - Hardware access & usage of Super()

Postby Nyh » Tue Oct 07, 2008 8:47 am

DrCoolZic wrote:By the way not directly related but ... Does someone now how to turn off all interrupts (critical section) directly from C ?

Happy I am only coding in Pure C. It seems it has less compiler bugs (still, it has some). This is how you enable and disable interrupts in Pure C:

Code: Select all

void move_sr(word value) 0x46c0; /* move D0,SR */

{
  move_sr(0x2700); /* disable interrupts */
  ..
  ..
  move_sr(0x2300); /* enable interrupts */
}


Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Wed Oct 08, 2008 4:01 pm

Nyh wrote:
DrCoolZic wrote:By the way not directly related but ... Does someone now how to turn off all interrupts (critical section) directly from C ?

Happy I am only coding in Pure C. It seems it has less compiler bugs (still, it has some). This is how you enable and disable interrupts in Pure C:

Code: Select all

void move_sr(word value) 0x46c0; /* move D0,SR */

{
  move_sr(0x2700); /* disable interrupts */
  ..
  ..
  move_sr(0x2300); /* enable interrupts */
}


Hans Wessels

Hi Hans. Can you be more explicit ? The above code does not compile and I have no idea about how it is suppose to work. I guess 2700 is disabling int by writing this value to SR and 2300 is restoring int in SR but I do not understand how it is suppose to do so ? The first problem is the "void move_sr(word value) 0x46c0;" that of course does not compile. Something missing ? (BTW I made word=long)

ppera

Re: C questions - Hardware access & usage of Super()

Postby ppera » Wed Oct 08, 2008 4:04 pm

SR has word (16 bit size). Of course writing to SR is privilig., so must be in supervisor mode.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: C questions - Hardware access & usage of Super()

Postby DrCoolZic » Thu Oct 09, 2008 6:53 am

Nyh wrote:Happy I am only coding in Pure C.
Hans Wessels

As you are the expert in usage of Pure C I have a question for you:
Compiler/Assembler/Linker options. It seems that there is two (three) ways of specifying options
    One is to use the option menu, select the program and set options in form. For example select compiler and sets options. In this case it seems that the options apply to all sources in project?
    Second is to specify in the project file some global options for example .C [-Y -P -K]
    Third is to specify for a specific source some specific options for example dma.c [-Y] (dma.h global.h)
It seems that the only options used are the one set from the menu in the PC "shell", all others comming from the project files seems to be ignored? Do you know what is the precedence in applying the options? Is there a way to force Pure C to use the options placed in the project file?
This is a pain. For example I made a LIB by setting -J option for the linker and later on made the executable using this lib but did not work because I had to go back to the linker option form to uncheck the -J option despite the fact that options were correctly set in the two project files ???
Another anoying things is that it seems that Pure C is not following the time stamp correctly if source file is updated outside of Pure C env ?
Thanks
Jean

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: C questions - Hardware access & usage of Super()

Postby Nyh » Fri Oct 10, 2008 8:36 am

DrCoolZic wrote:Hi Hans. Can you be more explicit ? The above code does not compile and I have no idea about how it is suppose to work. I guess 2700 is disabling int by writing this value to SR and 2300 is restoring int in SR but I do not understand how it is suppose to do so ? The first problem is the "void move_sr(word value) 0x46c0;" that of course does not compile. Something missing ? (BTW I made word=long)


There is not much to be said about the code. But I made a minimal example for you which compiles and executes fine on my system:

Code: Select all

#include <tos.h>

void move_sr(unsigned int value) 0x46c0; /* move D0,SR */

void handle_interrupts(void)
{
  move_sr(0x2700); /* disable interrupts */
  /* modify hardware registers here */
  move_sr(0x2300); /* enable interrupts */
}

int main(void)
{
  Supexec((long)(handle_interrupts));
  return 0;
}

Usually you write into interrupt registers or vectors while the interrupts are disabled. I know I do.

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: C questions - Hardware access & usage of Super()

Postby Nyh » Fri Oct 10, 2008 8:57 am

DrCoolZic wrote:As you are the expert in usage of Pure C I have a question for you:
Compiler/Assembler/Linker options. It seems that there is two (three) ways of specifying options
    One is to use the option menu, select the program and set options in form. For example select compiler and sets options. In this case it seems that the options apply to all sources in project?
    Second is to specify in the project file some global options for example .C [-Y -P -K]
    Third is to specify for a specific source some specific options for example dma.c [-Y] (dma.h global.h)
It seems that the only options used are the one set from the menu in the PC "shell", all others comming from the project files seems to be ignored? Do you know what is the precedence in applying the options? Is there a way to force Pure C to use the options placed in the project file?
This is a pain. For example I made a LIB by setting -J option for the linker and later on made the executable using this lib but did not work because I had to go back to the linker option form to uncheck the -J option despite the fact that options were correctly set in the two project files ???

I don't know the exact precedence of the options. I have to look-up that in the documentation. But to build a library I don't set the -J flag in the linker options but simply set the J flag in the project file:

Code: Select all

compress.lib
.C[ -K -P -Y -I..\include ]
.L[ -J ]
.S[ -S -Y ]
=
decode.c   (..\include\compress.h, decode.h, ..\include\gup.h)
crc.c      (..\include\crc.h, ..\include\gup.h, ..\include\compress.h, st_opti\opti.h, ..\include\gup.h)
encode.c   (..\include\arjbeta.h, ..\include\compress.h, ..\include\gup.h, ..\include\gup_err.h, st_opti\opti.h, evaluatr.h, encode.h, ..\include\gup.h)
evaluatr.c (..\include\arjbeta.h, ..\include\compress.h, ..\include\gup.h, ..\include\gup_err.h, st_opti\opti.h, evaluatr.h, encode.h, ..\include\gup.h)
sld.c      (..\include\arjbeta.h, ..\include\compress.h, ..\include\gup.h, st_opti\opti.h, encode.h, ..\include\gup.h)

st_opti\st_opti.c  (..\include\arjbeta.h, ..\include\compress.h, ..\include\gup.h, st_opti\opti.h, encode.h)
st_opti\chaoscrc.s    ; fast chaos crc routs, 3kB buffer
st_opti\encodest.s     (st_opti\command.mac)
st_opti\sld.s          (st_opti\command.mac)

This build de compression library and is called from an other project file building ARJBETA.

DrCoolZic wrote:Another anoying things is that it seems that Pure C is not following the time stamp correctly if source file is updated outside of Pure C env ?

On a real Atari this works correct. On STeem Atari's it depends. On the STeem at home the compiler sees the edited file and will compile it. On the STeem at work it doesn't. I haven't got a clue why. But the simulated Atari (running at 40 MHz) is fast enough to cope with it and I simply press Alt-x to rebuild the whole project.

Hans Wessels

mikro
Atari God
Atari God
Posts: 1620
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: C questions - Hardware access & usage of Super()

Postby mikro » Thu Jan 15, 2009 12:13 pm

DrCoolZic: I didn't follow all your post but yes, the situation is as you mentioned -- you *have* to call Super() from the same level. In case you can't (don't want to), you can always use longjmp C functionality (http://en.wikipedia.org/wiki/Longjmp)

Nyh: "void move_sr(unsigned int value) 0x46c0; /* move D0,SR */" is the coolest thing I've seen to do in C in years! I can't believe it even works! ;-) Is it compliant for all C compilers?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: C questions - Hardware access & usage of Super()

Postby Nyh » Thu Jan 15, 2009 12:23 pm

mikro wrote:Nyh: "void move_sr(unsigned int value) 0x46c0; /* move D0,SR */" is the coolest thing I've seen to do in C in years! I can't believe it even works! ;-) Is it compliant for all C compilers?

No. AFAIK it only works with Pure C. But I am not an expert on different compilers. I have been working with Pure C since it was called Borland C. I is a good compiler and I never had the urge to switch. Even now I do development in Pure C even when I compile the final result with GCC.

Hans Wessels


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 3 guests