wb program init in assembler

[Piru]

@Tickly:

Careful there! You should know what you're talking about when you try to instruct people.

That Forbid() is *absolutely required* and there must *not* be Permit()!

That Forbid() guarantees the Workbench don't have a change to UnLoadSeg() the seglist of the program while the program is still executes.

If there is no Forbid(), the ReplyMsg() results in task scheduling, and Workbench get change to run. Workbench UnLoadSeg() the seglist, and the last few instructions are executed on unallocated memory. This will lead into crashes.

There is no need for final Permit(), since the process will RemTask(NULL) itself eventually (default Task EndPC), and this completely removes the process anyway.

However, programs run from CLI *MUST* call Permit() for each Forbid() since the final 'rts' drops back to shell, and does not terminate the process.

I hope I didn't get too technical here. Anyway the point is, that itix's example is 100% correct. This is the standard way to handle program startup.

PS. This all is explained on developer CD and various other programming guides.

[edit: some cleanup]

[Piru]

;
; Workbench startup code
;

_LVOForbid   EQU -$84
_LVOFindTask EQU -$126
_LVOGetMsg   EQU -$174
_LVOReplyMsg EQU -$17A
_LVOWaitPort EQU -$180

pr_MsgPort   EQU $5C
pr_CLI       EQU $AC


; WBStartUp code - entry point
;
startupcode:

move.l  (4).w,a6

; Save original CLI commandline args.
;
move.l  d0,d2
move.l  a0,a2

; Find process pointer of self.
;
sub.l   a1,a1
jsr     _LVOFindTask(a6)
move.l  d0,a4

; If pr_CLI is non-NULL then the program was started from shell.
; In this case don't bother with further processing. Just
; jump to main routine (and exit in there).
;
tst.l   pr_CLI(a4)
bne.b   _main

; Wait for the Workbench startup message to arrive.
;
lea     pr_MsgPort(a4),a0
jsr     _LVOWaitPort(a6)

; Get the Workbench startup message pointer.
;
lea     pr_MsgPort(a4),a0
jsr     _LVOGetMsg(a6)
move.l  d0,-(sp)

; Call the actual program code. Argument pointer (a0) will
; be NULL. D0 contain pointer to WBStartup Message
; (see workbench/startup.i).
;
move.l  d0,d2
sub.l   a2,a2
bsr.b   _main

; Save RC for final return.
;
move.l  d0,d2

; Forbid to avoid Workbench from unloading our seglist while
; we execute it.
;
move.l  (4).w,a6
jsr     _LVOForbid(a6)

; Reply WBStartup message. This will instruct Workbench to
; unload the seglist of the program.
;
move.l  (sp)+,a1
jsr     _LVOReplyMsg(a6)

; Set final RC and return with original stack pointer.
;
move.l  d2,d0
rts


_main:

move.l  d2,d0
move.l  a2,a0

;
; ...actual program code follows, exit with 'rts', d0 containing RC.



[NOTE: This code snippet doesn't explain the WBStartup message itself. Check workbench/startup.i for details.]

[Piru]

This is true, but in most cases Forbid()/Permit() pairs can and should be avoided; Semaphores come in very handy here

This is true, but in most cases ObtainSemaphore()/ReleaseSemaphore() pairs can and should be avoided; Locking-free design come in very handy here

Ok, now I'm being a smartass, you're right, semaphores should be used when possible. Forbid()/Permit() should only be used when there is no alternative.

[Piru]

Considering that the Amiga doesn't have proper threads, when using multithreaded programs, Semaphores can be very useful for things like access to memory pools, lists that could be modified by other threads, etc. etc.

Well that's what Semaphores are for.

But if you can make without, the better. Totally asyncronous routines are even better (albeit harder to implement, and not suited for everything).

Are we both happy now? ;-)