Speak registers a RISC_OS "Linear Sound Handler" (SWI &40145) which
runs as an interrupt (IRQ mode? I'm not sure of the correct
terminology) whenever the sound DMA needs filling.  Speak's sound
handler takes items from this wcmdq and converts them to the sound
waveform to put into the sound DMA.

When the wcmdq gets low, the sound handler sets a transient callback
(SWI &54) to ask the OS to run the user mode part of the module to
convert some more text->phonemes->wcmdq.

This all works properly in the currently available Speak version 2,
where the sound handler is written entirely in assembler.

I'm now trying to port a re-write which I did on Linux
(espeak.sourceforge.net) to RISC_OS.  I don't want to write the sound
waveform generation code in assembler, so the only assembler code is a
few lines of the sound handler which calls a C function and then sets
the callback if needed.

But calling the C function from the sound handler gives:
   not enough memory - stack overflow
   filecore in use
(which of course means the system then needs a restart).

The callback-setting is commented out, so that's not the problem.

Calling a dummy C function (one which just assigns a couple of
variables) is OK.  No error.

Calling a dummy C function which then calls another dummy C function
gives the error and doesn't return.

I've checked the ARM procedure calling protocols and I think that's OK.
The test code is:

 IMPORT DummyProc1

 DMA_Handler
 ;**********
 ; linear sound handler, fill the sound DMA
 ; preserve r11,r12,r13 (fp,ip,sp)
 ; r1,r2 start and end of DMA buffer

        MOV     r5,ip           ; need to save ip
        MOV     ip,sp           ;set up a stack
        STMFD   sp!, {fp,ip,lr,pc}

        MOV     r6,r1           ;DMA start  16 bit sound
        MOV     r7,r2           ;DMA end

        SUB     r0,r7,r6        ;r0 = size of DMA buffer
 BL  DummyProc1      ; which then calls DuumyProc2

 NOP
 MOV ip,r5
        LDMFD   sp, {fp,sp,pc}   ; procedure exit from Sound Handler

When the error occurs, the NOP isn't reached (i.e. DummyProc1 doesn't
return).

Am I doing something wrong, or is it just not possible to call a chain
of C functions from assembler in general, or from a sound handler in
particular?

The PRM says the previous linear sound handler should be restored
immediately that a task or module has finished play back. This means if
the linear handler that your handler superceded naively deregisters
then it will cause your linear handler to be displaced. Worse, when
your client attempts to deregister it will restore a handler that no
longer exists (resulting in a big crash). The only guard against this
is for tasks or modules with handlers that have been superceded to
refuse to quit (thus forcing the user to quit them in reverse order of
registration).

In my opinion replacing the default linear handler (SharedSound) is
just as anti-social as replacing the default channel handler
(SoundChannels) was in the old days. But perhaps you have good reason.

The thing about interrupts is very important because if they were
enabled then you would be unable to do anything that corrupts R14_IRQ
(not even use the BL instruction!). This would definitely rule out
compiled C code. However it appears that unlike an 8 bit voice
generator, interrupts are not enabled upon entry.

Your C code mustn't attempt to access static data because the pointer
to the base of static data for a given module instantiation is assumed
to be stored 536 bytes below the stack limit. I imagine this would be
difficult to replicate in your veneer.

You will instead have to define a C structure to hold the static data
required by your buffer fill code (so that the format is known) and
pass a pointer to this in R2 when registering your sound linear
handler. This pointer will be passed to your handler code in a1/r0.

In your C program somewhere during initialisation, you need to take a copy
of those two words and store them, e.g. in a struct:

  typedef struct reloc_modifiers_t reloc_modifiers_t;
  struct reloc_modifiers_t
  {
    uint32_t lo;
    uint32_t hi;
  };

So, you'll need to have an assembler function to do the job:

  EXPORT  Asm_Init

 Asm_Init
  STMFD   SP!, {LR}
  MOV     R1, SP, LSR #20         ; base of SVC stack is MB-aligned
  MOV     R1, R1, LSL #20
  LDMIA   R1, {R2-R3}
  STMIA   R0, {R2-R3}
  LDMFD   SP!, {PC}

and the C prototype looks like:

  extern void Asm_Init(reloc_modifiers_t *reloc_modifiers);

Then you'll need to call it somewhere in your module initialisation, thus:

  static reloc_modifiers_t reloc_modifiers = { 0, 0 };

  ...

  Asm_Init(&reloc_modifiers);

Now, you need to pass the address of your reloc_modifiers structure as the
value in R12 for your handler(s) when you register them (or, make sure you
can access the structure via whatever address you do have in R12). That way,
your assembler veneer can fix-up the stack words before calling the C
function.

Here's an example of a fairly general-purpose ATPCS-compatible assmbler
veneer for calling a C function at the address is given in R4, parameters
are passed in R0-R3.

  ; R0-R3 = parameters
  ; R4   -> C function
  ; Corrupts R0, R14
 Generic_Veneer
  STMFD   SP!, {R1-R3, R10-R12, LR}
  ; Preserve whatever stuff is at the base of the SVC stack...
  MOV     sl, sp, LSR #20
  MOV     sl, sl, LSL #20
  LDMIA   sl, {fp, lr}
  Push    "fp, lr"
  ; Load our C relocation modifiers...
  LDMIA   ip, {ip, lr}
  MOV     fp, #0
  ; Store them at the base of the SVC stack...
  STMIA   sl, {ip, lr}
  ADD     sl, sl, #|_Lib$Reloc$Off|
  ; Branch (with link) into the client function...
  MOV     fp, #0
  MOV     lr, pc
  MOV     pc, R4
  ; Restore the original stuff to the base of the SVC stack...
  Pull    "fp, lr"
  SUB     sl, sl, #|_Lib$Reloc$Off|
  STMIA   sl, {fp, lr}
  LDMFD   SP!, {R1-R3, R10-R12, PC}

Note: |_Lib$Reloc$Off| is a magic number with the value 540.

You're actual IRQ handler might look something like this:

  IMPORT  C_IRQ_Handler
  EXPORT  irq_handler

 irq_handler
  STMFD   SP!, {R0, LR}
  MOV     R0, #some int value
  MOV     R1, #another value
  ADRL    R4, C_IRQ_Handler
  BL      Generic_Veneer
  CLRV
  LDMFD   SP!, {R0, PC}

and would have a C function prototype like this:

  extern void irq_handler(void);

So now you're finally in a position to register the handler:

  extern void C_IRQ_Handler(uint32_t some_value, uint32_t another_value);

  ...

  _swix(RegisterIt, _INR(0,2), IRQ_1, &irq_handler, &reloc_modifiers);

Words of warning: you'll need to be a C module, of course, because an
application may be paged-out when the IRQ is raised. You should also be
careful of the fact that your stack chunk is fairly small. All code here is
presented as an example rather than being tried and tested.

Hope that helps,

Steve

Where do I find api details of how to use it?

http://sudden.recoil.org/stronghelp/

--
David Pitt.

BTW, nice to see you around.

Best wishes,

John

--
David Pitt.

The "callback" type of handler sounds like it might be similar to the
callback that the (Linux) PortAudio library provides.

The handler that I provide has to exit with bit 0 of R3 set to 1.  So
my handler must be in assembler.  However can it immediately call a C
function of the type: ?

  void MyCallbackHandler(int param, char *start, char *end, int flags)

i.e.

Handler:
  STMFD  r13!,{fp,lr]
  BL  MyCallbackHandler

  MOV r3,#1
  LDMFD  r13!,{fp,pc}

or is it more complicated than that?

If you want the convenience of the C runtime system and standard
library you need to provide the right environment for it in your
assembler veneer.

In Speak v2, my (assembler) Sound Handler set up a transient callback
(SWI &54) which directly called a C function, through a line in the
cmhgfile (module header file):

   irq-handlers: callback_entry/MyCallbackHandler

where
   int MyCallbackHandler(_kernel_swi_regs *r, void *pw)

is a C function which calls other C functions in the module without
worrying about stacks or interrupts. Perhaps I was just lucky that it
worked :-)

Isn't the SharedSound "callback" type handler something similar?  

---druck

Steve

Your buffer fill function (written in C) should be declared as follows:

#include <stdint.h>

typedef struct {
  uint32_t flags;
  void *silence_fill;
  void *data_fill;

(Calling the generic buffer fill routines provided by recent versions
of the SharedSound module from within C code is a whole different can
of worms that I'm not going to open.)

Here is the assembly language source for the veneer that you should
register with SWI SharedSound_InstallHandler. When registering your
SharedSound handler you must pass a pointer to your module's private
word in R1 (so that it will arrive at the veneer in R0).

The entry point 'old_sharedsound_veneer' is a wrapper for use with
versions of the SharedSound module earlier than 1.03. This will allow
your fill code to use some extra flags introduced in later versions
(which are handy for making optimisations).

old_sharedsound_veneer
  ; Older versions of SharedSound don't correctly support all flags
  STR lr,[sp,#-4]! ; push return address

  CMP v4,#0 ; is volume 0?
    ORREQ a4,a4,#(1<<31) ; yes - set mute flag
  CMN v4,#1 ; is volume &FFFFFFFF?
    ORRNE a4,a4,#(1<<30) ; no - set 'not full volume' flag

  BL sharedsound_veneer

  BIC a4,a4,#(1<<30) + (1<<31) ; clear mute and N.F.V. flags
  LDR pc,[sp],#4 ; pull return address

sharedsound_veneer
  ; SharedSound immediate handler (IRQ mode, interrupts disabled)
  ; a1 = pointer to module's private word
  ; a2-a4, v1-v5 (R1-R8) = SharedSound parameters (see documentation)
  STMDB   sp!,{a1-a3,v1-v6,sl,fp,ip,lr} ; push caller registers
                                        ; (R0-R2, R4-R12, R14)

  TEQ     pc,pc ; Check whether 26 bit or 32 bit mode
    MOVNE   v6,pc ; preserve processor mode in v6
    ORRNE   ip,v6,#3
    TEQNEP  ip,#0 ; change to SVC mode (26 bit OS)

    MRSEQ   v6,CPSR ; preserve processor mode in v6
    ORREQ   ip,v6,#3
    MSREQ   CPSR_c,ip ; change to SVC mode (32 bit OS)

  STMDB   sp!,{v2-v5} ; Push last four arguments of C function onto SVC
stack
  MOV     a4,v1       ; registers v1-v5 are now free for reuse

  MOV     v3,lr ; preserve link register of SVC-mode foreground process
                ; (R13/sp and R14/lr are private for each processor
mode)

  MOV     sl,sp,LSR #20 ; calculate stack limit (base of the SVC stack
  MOV     sl,sl,LSL #20 ; is always on a megabyte boundary)
  LDMIA   sl,{v1,v2} ; preserve two words at base of SVC stack in v1,v2

  LDR     a1,[a1,#0] ; get pointer to module's workspace from private
word
  LDMIB   a1,{fp,ip} ; get C relocation modifiers from module workspace
  STMIA   sl,{fp,ip} ; store relocation modifiers at base of SVC stack
  ADD     sl,sl,#540 ; increment stack limit so the relocation
modifiers
                     ; are at the offset expected by compiled C code

  MOV     fp,#0 ; zero the frame pointer (otherwise stack backtraces
break)

  MOV     a3,a4 ; Finish marshalling arguments for C function
  MOV     a2,a3
  MOV     a1,a2
  BL      sharedsound_handler ; call C function (preserves
v1-v6,sl,fp,sp)
                              ; returns updated flags in a1

  SUB     sl,sl,#540
  STMIA   sl,{v1,v2} ; restore values originally at base of SVC stack
  MOV     a4,a1 ; must return updated SharedSound flags in R3/a4 not a1

  ADD     sp,sp,#(4*4) ; restore SVC stack pointer
  MOV     lr,v3        ; restore SVC link register

  TEQ     pc,pc ; Check whether 26 bit or 32 bit mode
    BEQ     32bit_exit

  TEQP    v6,#0 ; restore original mode (26 bit OS)
  MOV     r0,r0 ; NOP to avoid problems on ARM2
  LDMIA   sp!,{a1-a3,v1-v6,sl,fp,ip,lr} ; pull caller registers &
return

32bit_exit
  MSR     CPSR_c,v6 ; restore original mode (32 bit OS)
  LDMIA   sp!,{a1-a3,v1-v6,sl,fp,ip,lr} ; pull caller registers &
return

Everyone please feel free to pick holes in my code.

Anyway, this all seems like a great deal of repeated effort for no
obvious gain. If I were you, I would make use of something that already
exists. As you've noted, UnixLib has an interface you can directly use
from C, and simply throw data at, and as a bonus, will work exactly the
same under Liinux. That RISC OS interface uses the DigitalRenderer
module, which you could also call the SWIs of directly if you didn't
want to use UnixLib.

OTOH, DR's source is in GCCSDK, so anyone could improve it to use SS.

By the way what is the last release of SharedSound?

I believe that there was also more detailed documentation (with
explanations and stuff ;-)), released by ESP, along with a more recent
version of SharedSound (1.0X?) which was usable on all machines.

Unfortunately, I can't find a link to it; it doesn't appear to be on the
ESP site which is where I thought I'd seen it.

Anyone care to oblige?

Best wishes,

Since my Google search yesterday turned up neither of these documents,
perhaps I should make the more up-to-date one publically available on
my web site (with the authors' permission of course).

http://www.exsoftpr.demon.co.uk/ssdoc.htm

It's about time all these disparate API specifications were collated into a
central resource - it's pretty tedious to have to plough through Google
search results for $API.