JOBS coded in assembly

[tcat]

Hi,

I'd love to follow in the discussion about jobs, started at Arrakis topic.
Basically I now know, a job has to start with the header and terminate itself at the end.

QL Technical Guide pg 20

jobs.png (11.28 KiB) Viewed 3266 times

Sample header, bottom of the code area:

Code: Select all

start    jmp      job_start    ; bra.s     job_start
         dc.w     0            ; dc.l      0
         dc.w     $4afb
         dc.w     7
         dc.w     'JobName'

Sample job exit:

Code: Select all

job_end
         move.l   d0,d3        ; signal err_no
         moveq    #mt_frjob,d0
         moveq    #-1,d1
         trap     #1

The Technical Guide also says that the top of the data area holds channel IDs open for a job before it was activated. This part I do not quite understand, are these IDs filled in by EXEC command?

Many thanks
Tom

[tofro]

Tom,

note the example I gave you started with

Code: Select all

    bra job_start
    dc.w 0
    dc.w $4afb
    dc.w 3
    dc.b "Job"

if you change the "bra" to a "jmp" or a "bra.s", the code will either not properly assemble (jmp) or not show the proper job name (bra.s) when you do a "JOBS" - it is important that the dc.w $4afb starts exactly 6 bytes after the code start.

What's in the data area when a job starts:

A job in QDOS can have channels opened for it when it is started. That is done with the "EX" command (note you need TK2).

Code: Select all

OPEN #3,con_
EX #3 TO mdv1_job
PRINT #3,"Hello"

will connect S*BASIC #3 to a pipe that talks directly to the job, the channelId of that pipe will be handed over to the job in the data area. Anything you "PRINT" to that channel can then be directly read by the job (By calling IO.FBYT with the channel id, for example).

Another possible S*BASIC example would be

Code: Select all

EX flp1_list_exe;"flp1_program_asm" TO flp1_paginate_exe to flp1_print_exe

(If you know a bit of UNIX, something along the line of

Code: Select all

cat program_asm|pag|lpr

Would do pretty much the same)

- Provided the programs are written to do what they are expected to, list_exe would list a file, pipe it into paginate_exe that would add page and maybe line numbers, piping it in turn to print_exe that would finally print it to the printer.

With a command line as above, EX creates the channels and hands them over to the jobs (both for input and output). A job that finds such arguments, could (doesn't need to, the channel handling is actually not mandatory) do as above.

The command line argument "flp1_program_asm" above would also end up in the data space as a normal string, after the channel ids. There it is ready to be picked up by the job just started. A nice way to hand over arguments to jobs, like the name of the file to list, as in the example above.

Hope this helps
Tobias

[tcat]

Tobias,

Ah, these are the pipes, now I see.

Sorry, I will stick to bra job_start, but ...

I was curious and tested these three variants, all leave $4afb at 6 byte offset, when job_start is close to code beginning, GST Assembler gives warnings about short branches be used instead. JOBS command reports them equally well with the job name, RJOB works on them too.

bra job_start

Code: Select all

   1                         
   2 0 00000000 6000000F     start    bra      job_start
                                               |
**** WARNING 47 -- line    2 -    0 - branch could be short
   3 0 00000004 0000                  dc.w     0
   4 0 00000006 4AFB                  dc.w     $4afb
   5 0 00000008 0007                  dc.w     7
   6 0 0000000A 4A6F624E616D          dc.b     'JobName'

bra.s job_start

Code: Select all

   1                         
   2 0 00000000 600F         start    bra.s    job_start
   3 0 00000002 00000000              dc.l     0
   4 0 00000006 4AFB                  dc.w     $4afb
   5 0 00000008 0007                  dc.w     7
   6 0 0000000A 4A6F624E616D          dc.b     'JobName'

jmp job_start

Code: Select all

   1                         
   2 0 00000000 4EFA000F     start    jmp      job_start
   3 0 00000004 0000                  dc.w     0
   4 0 00000006 4AFB                  dc.w     $4afb
   5 0 00000008 0007                  dc.w     7
   6 0 0000000A 4A6F624E616D          dc.b     'JobName'

I also learnt that the code has to be padded to even size, otherwise it has problems executing, at least on my JS-ROM.

Code: Select all

;
        dc.w    0               ; padding even size!!!!
        end

Many thanks
Tom

[tofro]

Tom,

as long as you are aware that you need to insert the correct # of padding bytes between the branch and the $4afb, it actually doesn't matter much what type of branch you use

The issue behind the job crashing when the code length is odd, has actually nothing to do with the code as such. The point is that the job allocation code in QDOS will place the data space at the next byte after the last byte of code - At the other end of the data space, it allocates the stack and the channel and command line parameters - If the data space starts at an odd byte, all that will also be allocated at an odd address and will crash the job as soon as the stack is referenced.

Have fun,
Tobias

[NormanDunbar]

This might help with the channels etc, http://qdosmsq.dunbar-it.co.uk/download ... ge_001.pdf and there are a couple of minor corrections here, http://qdosmsq.dunbar-it.co.uk/download ... ge_002.pdf.

HTH

Cheers,
Norm.

[tofro]

This might help with the channels etc, http://qdosmsq.dunbar-it.co.uk/download ... ge_001.pdf and there are a couple of minor corrections here, http://qdosmsq.dunbar-it.co.uk/download ... ge_002.pdf.

HTH

Cheers,
Norm.