cmd_tail

[HSE]

Hi all!

I was thinking that cmd_tail function don't worked at all. I don't remember what test I made, but perhaps failed because almost nothing 

The function in SDK don't preserve registers:

Code ("Original cmd_tail.asm") Select Expand

    mov rax, r14                        ; return output buffer in RAX
    ret
  zeroexit:
    mov rax, r14
    mov BYTE PTR [rax], 0              ; zero 1st byte of r14
    mov rax, r14                        ; return zeroed buffer in RAX
    RestoreRegs
    ret

That can be changed to:

Code ("Modification cmd_tail.asm") Select Expand

    mov rax, r14                       
    jmp exit                            ; return output buffer in RAX
  zeroexit:
    mov rax, r14                        ; return zeroed buffer in RAX
    mov BYTE PTR [rax], 0              ; zero 1st byte of r14
  exit:
    RestoreRegs
    ret

And work pretty well 

Regards, HSE.

[jj2007]

The second line solves a serious problem with cmd_tail:

Code Select Expand

  lbl:
    call cmd_tail ; get commandline
    mov byte ptr [rax+r13], 0 ; put zero delimiter
    mov pFile, rax ; store rax in variable
Inter alia, the missing zero delimiter was the reason why the Project macros didn't work when teditor was invoked from the commandline with the filename as argument.

[sinsi]

Code Select Expand

    mov r12, rvcall(GetCommandLine)
    mov r13, len(r12)
    mov r14, alloc(r13)
Does len take into account the zero terminator?
Otherwise alloc would be one byte short (which would probably be swallowed by alignment, but...)

[jj2007]

The proper solution would clearly be to fix the library source, i.e. cmd_tail.asm

[HSE]

Does len take into account the zero terminator?

Fantastic Sinsi. That it's the point.

Then must be:

Code Select Expand

    mov r12, rvcall(GetCommandLine)
    mov r13, len(r12)
    add r13, 1
    mov r14, alloc(r13)

[Rockphorr]

Does len take into account the zero terminator?

Fantastic Sinsi. That it's the point.

Then must be:

Code Select Expand

    mov r12, rvcall(GetCommandLine)
    mov r13, len(r12)
    add r13, 1
    mov r14, alloc(r13)

Why uses add instead inc ?

[NoCforMe]

Because it'll make it 0.00001% faster?

[sinsi]

Why uses add instead inc ?

Long ago, a guru told us to

16.2 INC and DEC
The INC and DEC instructions do not modify the carry flag but they do modify the other
arithmetic flags. Writing to only part of the flags register costs an extra µop on some CPUs.
It can cause a partial flags stalls on some older Intel processors if a subsequent instruction
reads the carry flag or all the flag bits. On all processors, it can cause a false dependence
on the carry flag from a previous instruction.
Use ADD and SUB when optimizing for speed. Use INC and DEC when optimizing for size or
when no penalty is expected.

[NoCforMe]

So what I wrote was true ...

[sinsi]

So what I wrote was true ...

Not sure about the percentage, but yes - for a particular series of CPU (early P4s I think).

[jj2007]

Use ADD and SUB when optimizing for speed. Use INC and DEC when optimizing for size or
when no penalty is expected.

We've tested that several times in the Lab. No difference.

[Rockphorr]

Use ADD and SUB when optimizing for speed. Use INC and DEC when optimizing for size or
when no penalty is expected.

We've tested that several times in the Lab. No difference.

 So, it is just the preferences.