Re: Maybe we should stop "Paging Beth Stone" already...

On Mon, 19 Sep 2005 07:21:17 -0400, wolfgang kern <nowhere@xxxxxxxxxxx> wrote:

Unfortunately this PIT frequency+divider wont allow exact settings
for even time values. I found just 50mS(20Hz) to be the only exact.
Perhaps this were once the base to define the 1.193180 Mhz/65535,
seems not just defined to avoid 50 and 60 Hz interfierence as this
two beccome very close [ie: 5d37h  50.00125718 Hz].

I think they just used the 3.579545 Mhz crystal that's used for color in televisions, probably because it was the cheapest one available, being in such wide use and all. Divide that by 3 and you get 1.193182. They were probably aiming for 1Mhz, and decided that was close enough.

If an INT or IRQ results in a PL-change it will swap ss:esp anyway
without swapping all contents of the TSS.


Oh yeah...  That'd be what those stack fields in the TSS are for...

As my all code run PL0, I may have not fully understood what I read so
far about IRQ ? ;)

Well, I haven't even written code to do this stuff, so you probably know more about it than I do.

Non-hardware drivers ... OK.
For me non-hardware devices belong to software and don't need 'drivers'.

So what do you think of a keyboard port driver, and then a seperate user space keyboard driver which deals with decoding scan codes and such?

Basically what I want in my OS is to be able to combine everything into a working system from user space. So if the actual hardware drivers aren't in user space, that's really not a big deal since the hardware drivers are just the ends of the chains.

So in my OS, you'd have a keyboard port, mouse port, and video card driver which just did the actual hardware interfacing, and nothing else. Then in userspace I'd have a keyboard driver, which read those nasty scancodes and made them more useful, and a mouse driver, which decoded the mouse's protocol and made it nice and easy. Then I'd have a program that I would call the multiplexer, which connects to the keyboard and mouse drivers, and the video card driver. It then makes available a service to which other programs can connect to, just like they would connect to the real keyboard/mouse/video, and it does the multitasking switching between them, so when you type a key combination on the keyboard to switch to a different task, the multiplexer starts paying attention to a different task, and it either ignores or buffers the output of the other tasks.

Then if, for example, you're making a dedicated system, you can leave out that multiplexer and connect the programs to the real keyboard/mouse/video drivers, so that task switching is no longer available.

What made me think of this is the complexities in getting something like PPP over TCP going, and how you basically have to write a program just to do it. In this OS, every program would do everything via IPC, so if you wanted PPP over TCP, then instead of telling the PPP program to connect to [serial][0][115200_8N1], you just tell it to connect to [network][tcp][216.49.81.19:4197], and it's quite happy to do so since it's the same IPC interface it would have seen anywhere else.

Say you want a friend in another city to hear what's on the radio in your town. You can connect your radio to your sound card, then type a command like "mp3tool --input raw,44100,16,stereo [sound][pcm][44100_16_stereo] --output mp3 [network][tcp][219.17.39.42:3294]" and on your friend's end, he just does the opposite. Now you could do the same thing in Linux with normal piping, but you'd have to have a program that knows how to read from the sound device on one end, and one which knows how to make internet connections on the other end. Here the mp3tool program doesn't know anything about what's going on, as [sound][pcm][44100_16_stereo] works exactly the same as [filesystem][readonly][/home/idiot/sound.raw], and [network][tcp][219.17.39.42:3294] works just like [filesystem][create][/home/idiot/sound.mp3].

Similarly, [filesystem] is an IPC service implemented by a user-space process, which connects to other things like [fat32][ide0_1] and [ext2fs][ide0_2_1], mounting them into a single filesystem unix style. Of course, if you don't want a common filesystem like in unix, you can tell your programs to save to [fat32][ide0_1][create][\My Documents\file.txt] and that will work the same as anything else. If you don't like the long drive name, then when you load the fat32 driver, you can tell it to export it's [ide0_1] filesystem as simply [drive_c], in which case programs then save to [drive_c][create][\My Documents\file.txt] instead.

Finally, that fat32 driver connects to [ide0_1] which is a PC hard disk partitioning driver, which connects to [ide0] which is the actual IDE driver that talks to the hardware. And that IDE driver also, of course, offers an IPC service called [ide1].

Now of course there's all kinds of TSS switches all over that plan, but like I said, I'd rather have an 800Mhz PC with the features I want than a 1Ghz PC without them.

So you optionally allow I/O-access in user space. Good, but wouldn't this
somehow be against your strict protection demands ?

There would be a permissions structure in place so that only programs with the proper permissions were allowed to get I/O access.

The driver would have to have I/O access regardless of wether it's a kernel process or a user-space process. I just don't want to give up protection that I don't have to give up, like isolated address spaces. So as long as drivers can have isolated address spaces and still function, then I want them to have them.

I also tend to have columns for
|address |opcode |source .... |comments
as this makes life easy for plain text storage/print and it allow
masking off unwanted fields without much software overhead.

I don't usually find the column type comments very useful. People tend to write things like this:

	mov 	ecx, 12 		; put 12 in ecx
	mov 	edi, [dest]		; load [dest] into edi
	mov 	esi, [src]		; load [src] into esi
      rep 	movsb 		; move 12 bytes

Now I can read assembly, so I don't need comments like that. So when I write comments, I assume that people can read assembly just fine, and instead try to help them out by documenting what the code does in general. Like this:

# ==================================================
section .text

# On entry, edi points to the buffer for this piece.
# data_of_tokens is a long piece of data number_of_tokens long.
# We have to find the word in this data, and note which number string it was.
# If it's not in there, we mark it as -1, and call label_lookup on it.

# The piece buffer has this format:
#   0: length of piece (1 dword)
#   4: tokenized piece (1 dword)
#   8: offset if it's a label, value if it's a number
#  12: section number if it's a label
#  24: piece string (the remaining bytes)

tokenize_piece: enter "tokenize piece"
  cld

  mov edx, edi; mov edi, data_of_tokens
  mov dword [token_attempt_number], 0

  do

    enter "looking for match"
      # See if piece matches
      push edi
        lea esi, [edx+24]
        mov ecx, [edx+0]; inc ecx  # include the null character
        repz cmpsb
      pop edi
    leave

    # If it's a match, we're done...
    if z

      # Save the token number.
      mov eax, [token_attempt_number]
      mov [edx+4], eax

      # Return...
      leave; ret

    endif

    # Since it didn't match, advance edi to the next string.
    enter "advancing pointer"
      xor ecx, ecx; dec ecx
      xor eax, eax; repnz scasb
    leave

    # Increment token number.
    inc dword [token_attempt_number]

    # See if that was the last one.
    if dword [token_attempt_number], number_of_tokens, ae

      # We tried all strings, token was not found...
      mov [edx+4], dword -1

      # See if it's a hex number...
      if dword [edx+0], dword 2, ae
        cmp byte [edx+24], '$'; jnz .not_hex
          call hexadecimal_number_decode
          jmp .return
        .not_hex
      endif

      # Maybe it's a decimal number...
      cmp byte [edx+24], '0'; jb .not_dec
      cmp byte [edx+24], '9'; ja .not_dec
        call decimal_number_decode
        jmp .return
      .not_dec

      # Well, then, it must be a label...
      call label_lookup
      jmp .return

    endif

  loop; .return

leave; ret

# ==================================================

Between the comments, the text in the enter macros, and the non-abbreviated function and variable names (e.g. "token_attempt_number" instead of "ta", or even worse, ebx), my programs are usually pretty easy to follow, at least in my opinion. You can just read the comments in that code and get an idea what it does in about 15 seconds. A lot of source I see you have to read over the instructions five times to get an idea what the function does.

Now that's the best example of commenting in my code I could find. To be fair, here's the worst:

  # This is complicated as hell.
  # It's also spagetti code.
  # That tends to happen when you flowchart.
  # I'll include a picture of the flowchart.
  # I'll not include comments since it's easier to look at the chart.

Now I have no idea what I did with that flow chart. Even so, it's got good function names and it makes use of if/else/endif macros, so it's not too hard to follow, it's just a bit confusing when you come across a section of code that looks like this:

    if al, ":", z
      call end_piece
      call new_piece
      call add_to_piece
      call end_piece
      call process_part
      jmp next_part
    endif

And you wonder what the deal is with all of those function calls.

I figured it out once it occured to me that the character in AL isn't part of any piece yet, so what it's doing is ending the last piece and then creating a piece that only contains the colon. So I guess even that wasn't too bad. But let me go pull a random piece of code out of Menuet:

drawwindow_III:

        pusha

        mov   edi,edx        ; RECTANGLE
        mov   eax,[edi+0]
        shl   eax,16
        mov   ax,[edi+0]
        add   ax,[edi+8]
        mov   ebx,[edi+4]
        shl   ebx,16
        mov   bx,[edi+4]
        add   bx,[edi+12]
        mov   esi,[edi+24]
        shr   esi,1
        and   esi,0x007f7f7f
        push  esi
        call  draw_rectangle
        mov   ecx,3
      dw3l:
        add   eax,1*65536-1
        add   ebx,1*65536-1
        mov   esi,[edi+24]
        call  draw_rectangle
        dec   ecx
        jnz   dw3l
        pop   esi
        add   eax,1*65536-1
        add   ebx,1*65536-1
        call  draw_rectangle

It almost might as well be a disassembler output. We've got two meaningful function names, one TLA-style label, and a bunch of unnamed constants and anonymous register variables, and we know it has something to do with a rectangle.

Now I'm sure I'd have a better idea what it did if I read over the entire source, but it's all written like that, so it would be a real headache.

One thing I have noticed that other people do and I don't, is that they'll sometimes put the main function at the bottom of the file, then the functions it calls above it, and the functions they call above them. So if you do read the entire file, you just read it from top to bottom, and every function or variable that's used you've already read. I tend to do the opposite, so to get the same effect you'd have to start reading from the bottom of my source code, which is a little more difficult.

  ________________________________________
   MOV AL,FF |CLC |RET
   mode:PM32 status:BRK!   EFL:00007632
   flags:        DPFAVR-NLLODITSZ-A-P-C
   CS:0028  EIP:000001FC [EIP]:C3F8FFB0
   SS:0008  ESP:0000FF50 [ESP]:000063F0
            EBP:00000080 [EBP]:FFFFC000
   DS:0020  ESI:00000000 [ESI]:0040FFFF
   ES:0020  EDI:00000008 [EDI]:0840FFFF
   FS:0030  EAX:00000000   DR7:00000000
   GS:0030  ECX:00000000   DR6:00000000
            EDX:00000000   DR3:00000000 gl
            EBX:00000000   DR2:00000000 gl
   CR4:00000000  LT:0000   DR1:00000000 gl
   CR3:00000000  TR:0000   DR0:001001FC Gl
   CR2:00000000    TSC:0000000000000000
   CR0:00000011 LIN:001000FC    _______ mS
   GDT:00100300 FFFF  IDT:00100400 07FF
  _________________________________________

Now that's nice. I like how it has the [esi] and [edi] type fields and the disassembly there at the top.
.

Relevant Pages

  • Re: Compiler bug in the DDK--be aware of it
    ... I am new to driver development. ... I traced it down to a bug in the compiler. ... mov edx, OFFSET FLAT:?Init ... mov esi, eax ...
    (microsoft.public.development.device.drivers)
  • Re: Assembly Code in 64 bit driver
    ... There is no equivalent of MOV, why should there be if you are going this far ... since there is little or no need for assembler in 99% of the ... Don Burn (MVP, Windows DDK) ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ...
    (microsoft.public.development.device.drivers)
  • Re: BugCheck 0xA when verifier enabled
    ... This crash can happen either the driver messes with Irp->AllocationFlags or frees the Irp using ExFreePool function instead of IoFreeIrp. ... 804ebfd9 8bb040010000 mov esi,dword ptr ... The issue do not occur at all when verifier is not enabled, and when it occurs, the stack trace does not point to my driver at all. ...
    (microsoft.public.development.device.drivers)
  • Re: asm test
    ... mov ax, 13h ... int 10h ... but the mouse cursor doesn't appear. ... You forgot to load a DOS-based mouse driver. ...
    (alt.lang.asm)
  • [patch 04/33] m68k: Atari keyboard and mouse support.
    ... Atari keyboard and mouse support. ... +static void atakeyb_rep; ... To compile this driver as a module, ...
    (Linux-Kernel)