AsmLib has a lot of updates and this is a discussion
of the window functions.  Two new library directories
were added: dcache and vt.  Each directory handles
a different window type.

dcache windows
---------------------

The dcache window directory has some sample code
but the real power of dcache was not demonstrated.
With dcache it is possible to write simple text animations
or rapidly updated displays.  dcache will only write out
data that has changed and do it in the fastest possible way.
This allows the programmer to focus on the application and
let dcache optimize display writes.

vt windows
---------------

The vt window directory has functions to create a
virtual terminal.  Programs, shells, and scripts can
be run in the vt window.  The AsmFile program now
uses "vt" to control its shell window.  Possibly a better
use of "vt" would be in a debugger.  The debugged
program could be run in "vt" window and then swapped in
and out as needed.

Both window types work in terminals or the console.
This makes some programming jobs easier.  One problem
with both window types is lack of multi character
support.  Most terminals now support 2 byte and 3
byte characters, but vt and dcache only recognize
the standard 8 bit character sets.

all the best, jeff
http://linuxasmtools.net

Hi all,
The web page has been updated... see http://linuxasmtools.net
For awhile the web page had a fast library called AsmLiba, but
this was eliminated and most of the code included with the
standard AsmLib.

There were lots of changes, mostly minor fixes, and a few
rewrites.  I'll try to summarize the changes tomorrow.

all the best, jeff

Hi all,
This is a ramble about various assembler activities.

My goal of developing a high speed event model
for assembler programs failed.  One Linux "man"
page suggested it may not work, and it didn't.
Simple cases work, but a complex signal operation
with timer going was a no go.  The big problem was
somewhere in kernel handling, but the race
conditions and lock-outs were enough to discourage
most mortals (programmers).

I've uncovered lots of problems and bugs while testing,
and most are fixed.  There are some programs that need
rewriting and a list of enhancements.  The next release
should be a improvement.  AsmRef now has more
example programs and fixes to some of the kernel
call descriptions.  On and on.

The new AsmLiba (high speed library) has grown
and gone through one rewrite.  I still need to
remove the signal event handling and replace
it with "ppoll" or "epoll" handling of events.  Both
of these kernel calls are Linux specific, but they
appear easier to use than the "select" call.

While testing the signal handling, all the
debuggers were useless.  Even "strace" had
trouble and didn't report real time signal
handling correctly.  Eventually, I had to
fill the programs with "print" statements
and write to log files.  It got very tedious,
so I wrote some quick and dirty macros
for nasm.  I'm sure they exist somewhere,
but a few hours of web searching did not
find anything.  Anyway, most use asmlib
to do most of the work. here are the macros:

;
; put 0ah in log file ( end of line)
; call with:  logeol
%macro logeol 0
   extern log_eol
   call  log_eol
%endmacro

;
; display text message on screen, cr/lf at end
; call with:  say "hello world"
%macro say 1
   [section .data]
   %%str: db %1
   db 0ah
   %%str_end:
   [section .text]
;----
   mov eax,4
   xor ebx,ebx
   mov ecx,%%str
   mov edx,%%str_end - %%str
   int byte 80h
%endmacro

;
; put string in log file, no cr/lf at end.
; call with:  logstr "hello world"
%macro logstr 1
   [section .data]
   %%str: db %1
          db 0
   [section .text]
;----
   extern log_str
   push esi
   mov esi,%%str ;data to write
   call  log_str
   pop esi
%endmacro

;
; put hex value of memory dword in log file.
; Note: the label must be enclosed in []
; call with: logmem [label]
%macro logmem 1
   extern log_hex
   push eax
   mov eax,%1
   call log_hex
   pop eax
;-----------
%endmacro

; put hex value of eax in log file
; call with: logeax
%macro logeax 0
   extern log_hex
   call  log_hex
;-----------
%endmacro

Note:  The macro "say" does not save registers, and this
should be changed.  The other macros save all registers.
I didn't verify these macros, it is possible they have typo's.

The vt100-vt220 display control sequence interpreter
is done and being tested.  This project allows programs
to create windows on either console or xterm.  The
benifit of vt windows are:
   1. program sets size and location of window.
   2. data in window can be read or written
   3. windows can be restored or moved
       easily
   4. programs running in window think they are
       on normal terminal.
   5. All stdin/stdout data passing to/from window
       is available to controlling program.

At present I've written a terminal program (like
xterm) for testing.  It works, but needs code
clean up.

The downside of making all these changes is
a lot of program warts and bugs.  I am trying
to stop redesigning everything and improve
stability.  The upside is a lot of assembler example
code for Linux that can act as a tutorial.

Cutting corners... Linux includes a big include
directory for all the kernel call parameters.  They
have a complex %ifdef structure that builds
each file to match the features compiled into
a local kernel.  For example: all Linux error
codes use a label like EAGAIN or EINTR.
These labels can be used in programs and
if the numberic value of an error changes,
the programs still work.

For simplicity and lazyness all these labels
are hardwired numbers in asmtools.  I'm
thinking about changing this, but suspect that
might add a few errors.  Which is better
constant improvement, or stability?

all the best, jeff

PS. due to sucessful eye surgery I may have a
few more years to work on asmtools.  For the
short term, we are expecting summer to finally
arrive here and that will slow things down.  Also,
there is the possiblity of puppies and they trump
coding <grin>.

Hi all,
The new version of nasm fails with asmtools compiles.
I have not tried to fix the problems yet, but here is
what I've seen so far:

1. all the statements with:  [section .bss align 4]
     give a warning.  I think this can be fixed by
     changing to:  [section .bss align=4]

2. the following macro now fails.


; B_STRUC is a more succinct method for using a Nasm structure
; definition within a DATA section. The first argument names a
; previously defined structure. The following arguments indicate
; the members of that structure to declare here.
;
; Please note that the fields of the structure must have been defined
; as local labels (i.e., with a dot prefix).

%macro B_STRUC 1-*
%push foo
%define %$strucname %1
%%top_%$strucname:
%rep %0 - 1
%rotate 1
resb %{$strucname}%1 - ($ - %%top_%$strucname)
%1:
%endrep
resb %{$strucname}_size - ($ - %%top_%$strucname)
%pop
%endmacro

all the best, jeff

Hi all,
The following short program demonstrates direct kernel
calls (avoiding int 80h).  For assembler programmers this
appears trivial, but it appears to have caused confusion for
those working in other languages.

   all the best, jeff

---- cut here - program start ---
;Programs can call kernel directly and bypass "int 80h" by
;looking up a kernel entry point on the stack.  The stack
;is organized as follows:
; - parameter count
; - parameter 1 (ptr to our name)
; - (additional ptrs here)
; - 0 = terminator for paramerer ptrs
; - enviro ptr 1
; - enviro ptr 2
; - (additional ptrs here)
; - 0 = terminator for enviro ptrs
; - aux information area, with dword pairs.  Each
;   pair consists of code,data.  The type of data
;   is specified by code.  A code of 20h is the
;   sysenter kernel entry address.
; - 0 = terminator for aux area
; - strings table
;
; compile with:   nasm -felf -g program_name
; link with:      ld program_name.o program_name
;
; The following code search the stack for kernel entry
; and stores it.  Then, it displays a message using the
; kernel entry vector.
;

   [section .text]
   global _start
_start:
   mov esi,esp
   mov ecx,2  ;find second terminator
lp1:
   lodsd 	 ;get stack value
   or eax,eax  ;zero?
   jnz lp1  ;loop if non-zero
   loop lp1  ;loop ecx times
lp2:
   lodsd 	 ;get code
   cmp eax,byte 20h
   lodsd 	 ;get data for this code
   jne lp2         ;jmp if wrong code
found_it:
   mov [syscall],eax ;save syscall ptr
;test sys call
   mov   eax, 4            ; write
   mov   ebx, 1            ; fd 1: stdout
   mov   ecx, msg          ; string to print (not 0-terminated!)
   mov   edx,msg_end - msg
   call  [syscall]
   mov   eax, 1            ; exit
   mov   ebx, 0            ; return value
   call  [syscall]
;----------
   [section .data]
syscall:    dd 0              ; for making syscalls
msg         db 0ah,"Syscall vector found", 0Ah
msg_end:

Hi all,
   I've given up on the "pthreads" model used by "C" programs.
   There are simple methods to do threads that are a little slower.
   One way to do it on multi-core processors is to start the processes
   and assign them to a core.  Here is a example that switches itself
   if multi-cores are found:

--- snip here, source code follows --
;example program, reports number of cores, and switches core if possible
;
;compile with:
;   nasm -felf -g jeff.asm
;   ld jeff.o  -o jeff /usr/lib/asmlib.a

   extern sys_getpid
   extern sys_exit
   extern sys_sched_setaffinity
   extern delay
   extern stdout_str

  global _start
_start:
;find number of cores
   mov ebp,buffer
   call is_multi_cpu ;eax=cores, ebx=processors
;report number of cores
   push eax
   mov edi,num_core_stuf
   call dword_to_ascii
   mov ecx,num_cores_msg
   call stdout_str
   pop eax
   cmp eax,1
   jbe do_exit
;find our core #
   mov ebp,buffer
   call our_core
   push eax  ;save core 0+
;report our core #
   call core  ;report
;change our core # (affinity)
   call sys_getpid ;get our pid in eax
   pop ebx  ;get current core#
   xor ebx,1 ;select alternate core
   mov ebp,buffer
   call select_core
;report core switched
   mov ecx,switch_msg
   call stdout_str
;delay
   mov eax,20000
   call delay
;find our core #
   mov ebp,buffer
   call our_core
;report changed core
   call core
;exit
do_exit:
   call sys_exit
;-----------------------------------
core:
   mov edi,our_core_stuf
   call dword_to_ascii
   mov ecx,our_core_msg
   call stdout_str
   ret
;---------------
   [section .data]
buffer times 800 db 0
num_cores_msg  db 0ah,'This processor has '
num_core_stuf: db '   cores',0ah,0
our_core_msg:  db 'We are running on core '
our_core_stuf: db '    ',0ah,0

switch_msg:    db 'Using sched_setaffinity to switch core',0ah,0
   [section .text]
;--------------------------------------
;input ebp = pointer to buffer of at least 800 bytes
;output: ecx=core count (this cpu)
;        ebx=siblings=total cpu count,includes cores
;
is_multi_cpu:
   mov ebx,proc_cpu ;get filename
   mov ecx,ebp
   mov edx,799  ;buffer size
   call read_all
; find siblings
   mov eax,'sibl'
   mov esi,ebp
   mov edi,ebp
   add edi,799
imc_lp1:
   inc esi
   cmp esi,edi  ;buffer+799
   je imc_error
   cmp eax,[esi] ;match?
   jne imc_lp1
   add esi,4
   cmp [esi],dword 'ings'
   jne imc_lp1  ;jmp if not found yet
;we have found 'siblings'
   add esi,byte 7 ;move past tab
   call ascii_to_dword
   push ecx  ;save value
; find cores
   mov eax,dword 'cpu '
   mov esi,ebp
imc_lp2:
   inc esi
   cmp esi,edi  ;buffer+799
   je imc_error
   cmp eax,[esi] ;match?
   jne imc_lp2
   add esi,4
   cmp [esi],dword 'core'
   jne imc_lp2  ;jmp if not found yet
;we have found cores
   add esi,byte 8 ;move past tab
   call ascii_to_dword  ;ecx=cores
   pop eax  ;get siblings
   clc
   jmp short imc_exit
imc_error:
   stc
imc_exit:
   ret

   [section .data]
proc_cpu: db '/proc/cpuinfo',0
   [section .text]
;------------------------------------------------
ascii_to_dword:
   xor ecx,ecx
   xor eax,eax
   mov bl,9
   cld
atd_lp:
   lodsb
   sub al,'0'
   js atd_exit
   cmp al,bl
   ja atd_exit
   lea ecx,[ecx+4*ecx]
   lea ecx,[2*ecx+eax]
   jmp short atd_lp
atd_exit:
   ret

;----------------------------------------
;ecx=buffer  ebx=file  edx=buf size
read_all:
   push ecx ;save buf
   push edx ;save buf size
   mov eax,5 ;open
   xor ecx,ecx
   xor edx,edx
   int byte 80h ;open file

   pop edx  ;get size
   pop ecx  ;get buffer
   mov ebx,eax  ;get fd
   mov eax,3  ;read
   int byte 80h

   mov eax,6
   int byte 80h ;close
   ret

;----------------------------------------------
dword_to_ascii:
   push byte 10
   pop ecx  ;set ecx=10
dta_recurse:
   xor edx,edx
   div ecx
   push edx
   or eax,eax
   jz dta_store
   call dta_recurse
dta_store:
   pop eax
   or al,'0'
   stosb
   ret
;--------------------------------------
;input: ebp = buffer of at least 799 bytes
;output: eax=core number we are running on
;
our_core:
   mov eax,224
   int byte 80h ;gettid
   mov edi,proc_stat_stuff
   call dword_to_ascii
   mov esi,stat_append
   mov ecx,6
   rep movsb

   mov ebx,proc_stat ;get filename
   mov ecx,ebp
   mov edx,799  ;lib_buf size
   call read_all
;find cpu entry
   mov ecx,38
   mov esi,ebp  ;buffer

oc_loop:
   lodsb
   cmp al,' ' ;end of entry
   jne oc_loop
   loop oc_loop

   call ascii_to_dword
   mov eax,ecx
   ret


;-------------------
   [section .data]
proc_stat: db '/proc/self/task/'
proc_stat_stuff: db '     '
stat_append: db '/stat',0
   [section .text]

;-----------------------------------------------
;ebx=core# 0,1,2, etc.
;eax=pid
;ebp=buffer of at least 128 bytes
select_core:
   mov [sc_pid],eax
;build mask
   mov edx,1 ;starting mask
   inc ebx ;adjust ebx
sc_lp1:
   dec ebx
   jz sc_10 ;jmp if flag built
   shr edx,1
   jmp short sc_lp1
sc_10:
;build mask, first clear the buffer
   mov ecx,128
   xor eax,eax
   mov edi,ebp
   rep stosb
   mov [ebp],edx ;store mask
;setup for call
   mov ecx,128  ;length of mask
   mov edx,ebp  ;ptr to mask
;ebx=pid
   call sys_sched_setaffinity
   ret


;-------------
   [section .data]

sc_pid dd 0

On Thursday 18 June 2009 10:20:25 rxantos wrote:
> asmedit, asmplan, asmproject, asmview and asmide leaves the console screen
> blue after its use. the problem corrects itself when a command with color
> is executed, but its anoying.
>
> asmmgr, asmfile correctly puts the screen back to its original colors.

Yes, terminal colors can be a problem and there are lots of options:

Some people set the color in their prompt string and put it in the
.bashrc file.  There is a HOWTO on this somewhere.

Another approach is to build a small script that sets all the terminal
parmeters including color.  This allows us to control line wrapping
and all the other features.  We can then run the script whenever the
display is wrong.

Another approach is to use a file manager to run programs and let
it setup defaults after each program runs.  I use this approach and
avoid most display setup problems.

The final approach is to rely on each program to restore the
defaults when it exits.  The problem with this approach is that
each terminal has its own default color setting.  It can be tedious
studying each terminal setup file to fix the color.  On my system
a "xterm" gives a white-on-black screen and "konsole" gives a
black-on-white screen.  It would be nice if each program could
read the current color and restore it, but I've not found a way to
do this.  It appears the best we can do is restore the terminal
default.

So..  Asmtools should always restore the termnal
default as you suggest.  Also, they need to clear the
screen and set other terminal defaults.  Probably, the
best way to do all this is create a library function and
add it to the end of all programs.

It's on the todo list.

Thanks for the bug reprot.

all the best, jeff

asmedit, asmplan, asmproject, asmview and asmide leaves the console screen blue
after its use. the problem corrects itself when a command with color is
executed, but its anoying.

asmmgr, asmfile correctly puts the screen back to its original colors.

On Friday 12 June 2009 13:23:10 Kohlrak wrote:
> What about sys_fork?

Yeah! most assembler programmers use sys_fork, but
all I've found in the thread libraries is sys_clone.  I don't
think sys_fork fits anywhere in the thread world.

My problem is that all the documentation of threads is
for users of a few libraries.  In this world you call the
function pthread_create and go from there.  I want to
use kernel calls (clone, set_thread_area, mutex, futex) to
create threads.

Almost all "c" programs today have a call to the kernel
function set_thread_area, but generally "c" programmers
don't know it is there... So it is poorly documented.

Just try a google on set_thread_area and see what you get.
All I've found is a "man" page and lots of error reports.
All this translates into a headache for writing threads in
assembler.  I've not found a single example or any
useful discussion.

I now have a semi-working thread, but the linux kernel
does not schedule it on a separate core of a multi core
processor.  Why??  That where I'm currently stuck.

all the best, jeff

>
> linuxasm@... wrote:
> > Hi All, this is a review of current projects
> >
> > The terminal project is being tested. The goal of this
> > project was to create a terminal widget that programmers
> > can embed into a program.
> >
> > To add more speed to functions, I've stated looking at
> > threads and supporting multi-core cpu's. So far I've
> > got a program to report current processor type and if
> > a process is running on core x. Also, a lot of small programs
> > to use the pthreads library.
> >
> > Since the Linux kernel schedules which core a process
> > runs on, we have to set up programs so the kernel can
> > make a choice. This means "threads" and using the
> > "pthreads" library with glibc.
> >
> > My goal is to create an assembler threads library. So far
> > this effort is struggling with the complexity of pthreads.
> > I've tried to disassemble the pthreads library, but the
> > static version had bugs, so they removed it. This means
> > everyone is using "dynamic" pthreads???
> >
> > Threads are complex.
> >
> > all the best, jeff owens
> > http://linuxasmtool s.net <http://linuxasmtools.net>

What about sys_fork?

linuxasm@... wrote:
>
>
> Hi All, this is a review of current projects
>
> The terminal project is being tested. The goal of this
> project was to create a terminal widget that programmers
> can embed into a program.
>
> To add more speed to functions, I've stated looking at
> threads and supporting multi-core cpu's. So far I've
> got a program to report current processor type and if
> a process is running on core x. Also, a lot of small programs
> to use the pthreads library.
>
> Since the Linux kernel schedules which core a process
> runs on, we have to set up programs so the kernel can
> make a choice. This means "threads" and using the
> "pthreads" library with glibc.
>
> My goal is to create an assembler threads library. So far
> this effort is struggling with the complexity of pthreads.
> I've tried to disassemble the pthreads library, but the
> static version had bugs, so they removed it. This means
> everyone is using "dynamic" pthreads???
>
> Threads are complex.
>
> all the best, jeff owens
> http://linuxasmtool s.net <http://linuxasmtools.net>
>
>

Hi All, this is a review of current projects

The terminal project is being tested.  The goal of this
project was to create a terminal widget that programmers
can embed into a program.

To add more speed to functions, I've stated looking at
threads and supporting multi-core cpu's.  So far I've
got a program to report current processor type and if
a process is running on core x.  Also, a lot of small programs
to use the pthreads library.

Since the Linux kernel schedules which core a process
runs on, we have to set up programs so the kernel can
make a choice.  This means "threads" and using the
  "pthreads" library with glibc.

My goal is to create an assembler threads library.  So far
this effort is struggling with the complexity of pthreads.
I've tried to disassemble the pthreads library, but the
static version had bugs, so they removed it.  This means
everyone is using "dynamic" pthreads???

Threads are complex.

all the best, jeff owens
   http://linuxasmtools.net

Hi,
This is a discussion of windows in Linux terminals.

I've been testing the fast cached dislay and a problem
surfaced.  Many debuggers don't show the app window
and the ones that do, are full of bugs.  What I want to do
is debug the program and watch it write to the screen.

This has been a problem for AsmTools also.  None of the
programs deal with windows very well.  AsmFile, AsmMgr,
MiniBug, AsmBug, all try to show a shell or app window at
times.  In fact, the venerable file manager "mc" does a very
poor job of handling a shell window.

I've tried many different ways to get around the problems
and each solutions has failed.  It appears there is only one
solution.  A complete VT-100/220 terminal with signal handlers
needs to be created inside the program.

So... AsmLiba tutorial needs a debugger (MiniBug/AsmBug), and
the debuggers needs a good widowing program, We also need a
window system for AsmFile and AsmMgr.  Sigh..

Doing a complete terminal from scratch in assembler will take
awhile.  On the other hand, it will be nice to have a general window
library for terminals and the console.

Anyway, work has started on a window library which will be part of
AsmLiba.  When complete, AsmLiba will have a fast cached window
system, a simple cached keyboard, and signal driven program
system.  All this will create a interesting set of terminal tools that
no one will use<grin>.

all the best, jeff

Yo!
The web page has the latest asmliba (event library).
It includes a template for creating programs with
lots of comments.   The template actually runs so
it was put in /demo directory.

The library was rewritten 3 or 4 times to get the
interface right.  This version looks stable so I'm
going to try applying it to a few programs.

Here is the template:
----------------------------------------------------------------

;Template using AsmLIba and AsmLib to create
;a high speed event driven program.
;
; * display is cached for speed.
; * keyboard is connected to signal SIGIO
; * display resize signal SIGWINCH is handled.
; * all abort signals are trapped and cleanup
;   code called to save work.
; * pipe of data through STDIN,STDOUT still
;   available to program.
; * easily extendable to other events
; * small and flexable, with most details hidden.

   [section .text]

%include "signal.inc"
%include "system.inc"
%include "dcache_colors.inc"

;external library calls follow
   extern dcache_flush,dcache_buf_cursor,dcache_write_string
   extern dcache_size,dcache_clear,dcache_setup
   extern event_setup,event_decode,event_wait,event_close
   extern m_setup,m_allocate
   extern sys_exit
   extern key_check
   extern key_remove
   extern signal_hit_mask
   extern delay
   extern key_setup

;The display is built in a buffer and then
;written with dcache_flush.  First, we need
;to find the display buffer size.
   global _start
_start:
   call display_setup ;allocate buffer for display
;
;catch all signals for maximum visibility and
;problem detection.
;
   mov eax,-1  ;enable all possible signal traps
   mov ebp,cleanup ;send abort signals here
   call  event_setup ;enable signal handlers
   call  key_setup ;attach keyboard to SIGIO signal
;
; build display here
;
restart:
   mov al,[color]
   call  dcache_clear ;clear display
   mov eax,0202h ;row 2 column 2
   call  dcache_buf_cursor ;move cursor
   mov esi,message
   call  dcache_write_string ;put msg in buffer
   call  dcache_flush ;write to screen
;
; wait for a signal
;
event_loop:
   call event_wait
   mov eax,decode_table
   call event_decode
   or eax,eax
   jz event_loop ;jmp if no events of interest
   jmp eax  ;goto event
;if event was not in table, we can decode
;it manually by looking at mask signal_hit_mask
;and refering to signal.inc for format.
;---------
   [section .data]
decode_table:
           dd  SIGCHLD_code  ; child died
           dd  SIGWINCH_code ; terminal resize
           dd  SIGTRAP_code  ; breakpoint/trap occured
           dd  SIGUSR1_code  ; event #1, user assigned
           dd  SIGUSR2_code  ; event #2, user assigned
           dd  SIGALRM_code  ; alarm/timer event
           dd  SIGURG_code   ; urgent socket event
           dd  SIGIO_code    ; key available
   [section .text]
SIGCHLD_code:  ; child died
   jmp event_loop ;ignore this signal
SIGWINCH_code: ; terminal resize
winch_loop:
   and [signal_hit_mask],dword ~_WINCH
   mov eax,-1
   call delay
   test [signal_hit_mask],dword _WINCH
   jnz winch_loop
   call display_setup
   jmp restart

SIGTRAP_code:  ; breakpoint/trap occured
   jmp event_loop ;ignore this signal
SIGUSR1_code:  ; event #1, user assigned
   jmp event_loop ;ignore this signal
SIGUSR2_code:  ; event #2, user assigned
   jmp event_loop ;ignore this signal
SIGALRM_code:  ; alarm/timer event
   jmp event_loop ;ignore this signal
SIGURG_code:   ; urgent socket event
   jmp event_loop ;ignore this signal
SIGIO_code:    ; key available
   call key_check
   jecxz event_loop ;jmp if no key avail
   cmp [ecx],byte 'q' ;quit key
   je cleanup
   call key_remove ;remove key from buffer
   jmp event_loop

cleanup:
   call event_close
   call sys_exit
;-----------------------------------------------
; setup the display by allocating a buffer
; to hold image and establish initial color.
;
display_setup:
   call m_setup  ;find top of memory
;dcache_size returns the total characters on
;display in ebx and a suggested display buffer
;size in eax.
   call dcache_size ;get size needed in eax
   jc ds_exit  ;jmp if size avail
   add eax,32  ;add extra
   push eax
   call m_allocate
   mov ebx,eax  ;buffer start to eax
   pop eax  ;get size of buffer
   mov dl,[color]
;we will use stderr for output to free
;the pipe on stdout for other uses.
   mov dh,2  ;use stderr
   call dcache_setup
ds_exit:
   ret
;--------------------
   [section .data]
color db black_char + grey_back ;black char on grey
message db  'line 2 column 2',0ah
       db ' press q to exit',0

   [section .text]

On Sunday 03 May 2009 20:06:46 Kohlrak wrote:
> I remember reading about signals when reading up on sockets... It isn't
> quite something that looks appealing to me, so i'm not surprised that
> not many know about it or use it. I'm interested in seeing some working
> examples or progress into this, as it may eventually lead to us assembly
> programmers actually getting some credit in this world of C that we call
> UNIX.

Right!  This may be an area we can exploit with assembler.
The kernel folks say signals were not intended for program
sequencing.  They prefer we use "select" or "poll" to handle
events in our programs.  If we want keyboard data, we do
a "read" function and wait till the data shows up.  Yuck!

I want the keyboard attached to an interrupt that fills
a buffer with data.

Anyway, I'm now trying to come up with a set of simple
library functions that handle signal driven programs.
I've written more examples and they all work, so this
idea is a go.  To be robust, we want to handle all signals
and have complete control.  This presents some problems
with SIGFPE and SIGSEGV signals.  The kernels default
action is to abort programs when divide or memory
errors occur.  I've noticed the kernel sometimes ignores
errors and this is even worse.

If we have a lot of data that needs saving before the
programs aborts, then we want SIGFPE to call a shutdown
and exit function.  With "C" code they provide a
siglongjmp function for this purpose.  It is a kludge
and I am looking for a way to hide all this from
a programmer.

All this is not easy to do with the "C" library, so we
may have a niche for assembler.  If you want to see
code, here is a fragment:

;attache keyboard to SIGIO and wait for signal.  We may
;need to put keyboard in raw mode before reading key.
;Probably best to set raw mode before all this.  Anyway,
;it gives an interrupt when key pressed.
;

%include "signal.inc"

   extern sys_exit
   extern open_tty
   extern get_our_process_id
   extern sigaction

   global main,_start
main:
_start:
;setup signal handler
   mov ebx,SIGIO
   mov ecx,sigio_handler
   call sigaction
;get process and tty
   call        get_our_process_id
   mov [our_id],eax
   call  open_tty
   mov [tty_fd],ebx
;set owner
   mov eax,55
   mov ebx,[tty_fd]
   mov ecx,8 	 ;F_SETOWN
   mov edx,[our_id]
   int byte 80h
;set state flags
   mov eax,55
   mov ebx,[tty_fd]
   mov ecx,4 	 ;F_SETFL
   mov edx,024000q  ;O_ASYNC O_NONBLOCK
   int byte 80h
;set alt signal
   mov eax,55
   mov ebx,[tty_fd]
   mov ecx,10 	 ;F_SETSIG
  mov edx,0 	 ;set SIGIO, 0=SIGIO not STDIN as expected
   int byte 80h
;wait for signal, sigsuspend
   mov eax,72  ;sigsuspend
   mov edx,mask
   int byte 80h
;expected code here is eax=-4
   mov al,[got_it]
    call sys_exit
;----------------------
sigio_handler:
   mov [got_it],byte 1
   ret
;---------------
   [section .data]
tty_fd dd 0 ;open fd
our_id: dd 0 ;our process id
got_it: db 0
mask: dd 0,0
   [section .text]
;----------------------------------------------------

all the best, jeff
   http://linuxasmtools.net

Hi All, this is a status report

I've been chasing bug, working on the AsmLiba tutor, and
researching signal usage. Everything was going quiet
until yesterday. Then.., AsmLiba suddenly morphed into
a new model for the ultimate high speed library.

We are doing assembler here, so might as well go
for speed and real time. That means everything
needs to be controlled by signals.

The kernel functions have been moving towards real
time controls and keeps adding functions for thing like
AIO, polling, threads, and other ideas to speed up processing.

If we could access all this using a few simple library calls,
our programs would leap in performance. So...
I began writing test programs yesterday, and found
a possible design.

The key to all this is in the following kernel functions:

sigsuspend - wait for any signal
fcntl F_SETOWN, F_SETFL, F_SETSIG
sigaction - attach code to signal

The signal SIGIO isn't used much, but can be
assigned to a file descriptor and give us a
signal when activity occurs. I tested this
on keyboard input and it works.

Then, buried somewhere was the comment that
we can assign other signals instead of SIGIO. If
that is true, we can put all events of interests on
signals and go totally async.

A google search found very few programmers aware
of the F_SETSIG function. Many of the example programs
didn't work and the major libraries ignored it. So... here
we have a open door.

Next, we enter the world of race conditions, stacked
events, and semaphores. Should be interesting...

all the best, jeff

Hi All, this is a status report

I've been chasing bug, working on the AsmLiba tutor, and
researching signal usage.  Everything was going quiet
until yesterday.  Then..,  AsmLiba suddenly morphed into
a new model for the ultimate high speed library.

We are doing assembler here, so might as well go
for speed and real time.  That means everything
needs to be controlled by signals.

The kernel functions have been moving towards real
time controls and keeps adding functions for thing like
AIO, polling, threads, and other ideas to speed up processing.

If we could access all this using a few simple library calls,
our programs would leap in  performance.  So...
I began writing test programs yesterday, and found
a possible design.

The key to all this is in the following kernel functions:

   sigsuspend - wait for any signal
   fcntl F_SETOWN, F_SETFL, F_SETSIG
   sigaction - attach code to signal

The signal SIGIO isn't used much, but can be
assigned to a file descriptor and give us a
signal when activity occurs.  I tested this
on keyboard input and it works.

Then, buried somewhere was the comment that
we can assign other signals instead of SIGIO.  If
that is true, we can put all events of interests on
signals and go totally async.

A google search found very few programmers aware
of the F_SETSIG function.  Many of the example programs
didn't work and the major libraries ignored it.  So... here
we have a open door.

Next, we enter the world of race conditions, stacked
events, and semaphores.  Should be interesting...

all the best, jeff

LinuxasmTools updates
------------------------------

For curiosity I installed the new 3D nvidia drivers and
all the AsmTool X programs died.  Trying to find the
problems, turned up errors in Tracex and with
asmbug.  Switching to minibug was painful and the
other Linux debuggers were not much better.  Finally,
I managed by using "insight" debugger.

Asmbug now works again, the AsmLibx functions that
connects to a X serever is changed, and Tracex works
better.  All this is now on the web page

There are now a few outstanding problems:
1. installing some .deb files fail.  Debs don't like
     to overwrite existing files?
2.  The AsmLiba (cache library) still needs a tutorial
    and more testing.
3. Minibug needs something?
4. The weather needs more stability.  We are
     having hot/cold flashes here.

all the best, jeff

Announce

The web page now has AsmLiba (fast cached display library)
ant the "HOWTO do fast text displays'

The AsmLiba_tutor is not available yet, but a stub
has been placed on the web page.

all the best, jeff
   http://linuxasmtools.net

Here is a first draft of a new howto.  The
library mentioned in the howto is complete
and tested, I'm now working on the tutorial.
None of this is on the web page.

                  ----------------

   Fast text displays mini-HOWTO
   jeff owens, jeff@...
   v1.01, 19 April 2009

   How to speed up text displays
   ______________________________________________________________________

   Table of Contents


   1. Disclaimer

   2. Introduction

   3. What is the problem?

   4. How do text displays work?

   5. What can we do?

   6. What solutions are available?

   7. Finding more information
   ______________________________________________________________________

1.  Disclaimer

   The following document is offered in good faith as comprising only
   safe programming and procedures. No responsibility is accepted by the
   author for any loss or damage caused in any way to any person or
   equipment, as a direct or indirect consequence of following these
   instructions.


2.  Introduction

   The most recent version of this document can always be found at
   http://linuxasmtools.net

   There has been a lot of interest in speeding up graphical
   displays, but little discussion of text displays.  Generally,
   text display speeds have been sufficient or a few design
   changes can fix the problems.   Also, graphical applications
   dominate much of the Linux world and their slow speed has
   grabbed programmer attention.  Should we spend time speeding
   up text displays?  This howto looks for some answers.

3. What is the problem?

   Is there a problem?  For most people the answer is: no!
   The few that are having problems assume it is due to slow
   hardware of something else.

   The symptoms of text speed problems are:
     * flickering displays
     * flashing areas of screen that are too fast
       to see.
     * parts of display updating slowly
     * And, the worst case, slow program execution.

   These problems occur normally when a computer is under
   heavy load, using older hardware, or running non-optimized
   display handling.

   It is difficult to know how may users have these
   problems, it may be quite high.

4. How do text displays work?

   There are three main areas of text usage on Linux,
   they are:

    * X window text
    * X terminal
    * console

   All text handling converts ASCII codes to a graphic
   using font tables.  The resulting pixels are written
   into display memory and a character appears.

4.1 X window text displays

   The X server talks directly to display memory and
   all text handling is internal to the server.  It
   is usually fast and of little interest to this howto.

   Additionally, xlib includes some features
   mentioned in this howto

4.2 X terminal displays and console displays

   Both X terminals and console displays use control
   codes embedded with the text.  They must scan
   the text for control codes such as line-feed,
   cursor movement, color selection, and many others.
   Once the control codes are processed, the remaining
   ascii is converted to a graphic using font tables.

   All this uses several layers of processing and may
   be fertile ground for optimization.

5. What can we do?

   If you look at the typical program, it builds a
   line of data, sets the display color, moves the
   cursor to start of line, and finally writes the
   line.

   We can save a little time by collecting all these
   operations into one text string and writing
   everything with one kernel call.

   We could speed things up a little more by collecting
   multiple lines and writing them all at once.

   We could put the display in wrap mode, and eliminate
   all the line-feed characters.

   We could track display location and color and only
   output control strings if a change occurs.

   We could keep track of what is already on the display
   and only send data if a area is changed.

   We could sort the data by display location and
   output data in sequence.

   We could collect all writes and only send the
   latest data for a area of the screen.

   Would all these changes make a big difference?
   For most programs that display a lot of text, they
   will make a huge difference.  Generally, programmers
   focus on their application and not on display
   optimization.  This means, the typical program
   has slow display logic.

   Isn't this too complicated for programmers to
   worry about?  It is complicated, but programmers
   don't need to worry about it.  Instead, all we
   need is a display handler to do it for us.

   The design we need is a cache (image of display)
   that can be read or written like a disk drive.
   This provides a series of additional advantages:

    * reading of data and colors from display
    * functions better matched to most applications.
    * ability to detect data that has not changed
      and does not need display update.

   The cache works by keeping a copy of each display
   character and its color.  Each character and
   color also has a flag which is set when the
   they are not in sync with display contents.

   When a write request comes in the data is
   compared to image contents and flags are
   set only if the data will change the display.
   The color is also tracked and if it changes,
   the flags are set to force a display update.

6. What solutions are available?

    The library asmliba provides all the features
    discussed in this howto and also includes a
    keyboard cache.  See section 7

    The AsmLiba_tutor has some example code and
    introduces the cache functions.

    The X server is usually called from xlib and it
    has a function cache.


7. Finding more information

     AsmLiba  - fast display and keyboard cache.
                http://linuxasmtools.net/asmliba.html

     AsmLiba_tutor - tutorial
                http://linuxasmtools.net/asmliba_tutorial.html

On Thursday 16 April 2009 12:54:49 Kohlrak wrote:
> That's why, when i have speedy output, I like to take advantage of >>.

Right!, that would have worked.  A better choice may be &> for
programs that send errors to STDERR.  I don't think we can
do a append log.  I've tried &>> without success.

>
> jeff wrote:
> > Hi All
> > AsmIDE was updated again. I found some
> > error messages were flashed up on the screen
> > and the used did not have time to read them.
> > It appeared as if the program failed silently.
> >
> > I did not see this problem when testing, because
> > the debugger slowed everything down and the
> > message appeared ok.
> >
> > The web page now has version 5
> >
> > all the best, jeff

That's why, when i have speedy output, I like to take advantage of >>.

jeff wrote:
>
>
> Hi All
> AsmIDE was updated again. I found some
> error messages were flashed up on the screen
> and the used did not have time to read them.
> It appeared as if the program failed silently.
>
> I did not see this problem when testing, because
> the debugger slowed everything down and the
> message appeared ok.
>
> The web page now has version 5
>
> all the best, jeff
>
>

Hi All
AsmIDE was updated again.  I found  some
error messages were flashed up on the screen
and the used did not have time to read them.
It appeared as if the program failed silently.

I did not see this problem when testing, because
the debugger slowed everything down and the
message appeared ok.

The web page now has version 5

all the best, jeff

Ah, thank you... I'll get on it as soon as i can (some thing just came
up and more of my time will be taken by them)...

Nathan Baker wrote:
>
>
> There are several ways to accomplish this.
>
> You can use the 'clock' system call and read the 'process CPU time'
> from the structure.
>
> You can use the 'getrusage' system call and read the 'user time used'
> from the structure.
>
> Or, you can use the 'times' (get process times) system call and see if
> it works the way it is documented.
>
> Nathan.
>
>
> ------------------------------------------------------------------------
> *From:* Shane U. Undisclosed <kohlrak@...>
> *To:* DesktopLinuxAsm@yahoogroups.com
> *Sent:* Saturday, April 11, 2009 5:35:18 PM
> *Subject:* [DesktopLinuxAsm] Benchmarking?
>
> I'm always told how SSE2 routines always beat the FPU's hard coded
> routines, however i've never actually seen this quantified. Yes, SIMD
> is good in theory, but can it really beat scalar routines? It uses
> more memory (more instructions streamed), and it's not hard coded.
> I've seen some C code trying to quantify this, but naturally the speed
> gain presented has not only been inconsistent (I assume the fault is
> in failing to consider the task scheduler), but the gain seems less
> than 10% every time for the functions that i feel matter the most
> (fsincos and atan). More so, I've found some code that is
> theoretically faster than a nice Taylor, and seems pretty accurate
> when i typed in the function on my TI-NSpire. I was wondering if
> anyone had any code laying around that they use to benchmark
> procedures while taking the schedualer out of the equation. It might
> also help the community in the event that they do not have a
> benchmarker handy to try other things.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>     (Yahoo! ID required)
>
>     mailto:DesktopLinuxAsm-fullfeatured@yahoogroups.com
> <mailto:DesktopLinuxAsm-fullfeatured@yahoogroups.com>
>
>
>
>

jeff wrote:

...
> The problem was a buffer overflow. Old memory conservation
> habits die hard. I fixed it and uploaded a new AsmIDE to web page.
> It is now version 4
> http://linuxasmtoos.net <http://linuxasmtoos.net>
>
>  > ext = 3<editor no like>

>  > I'm not familiar with the syntax. Is that correct?
>
> If you see it again, we can call it a feature. Maybe the
> GNU folks will modify their development tools to accept
> it. Eventually, it might get to the NSA folks and they will
> think it a secret code. That should add some activity
> to this list.

:) Hi guys!

>  > Assembling and linking "by hand" with the same command-lines works fine.
>  > Having done so, and restarting asmide, F4 starts up minibug, but
>  > stepping through it, the display is strange - seems like only the middle
>  > few lines are scrolling(?). The instruction I'm about to step through
>  > doesn't seem to be displaying(???).
>
> Whoa??? I was not able to reproduce this. One problem might
> be my color selection for the current instruction at EIP. On my
> system it is a light bar for the background and a slightly darker
> color for the forground text. On other monitors in may be a
> problem???

Now that you mention it, my monitor just died and the colors are "weird"
right now on the one I replaced it with. Problem is probably on my end.

>  > keep gettin' distracted!

Still too distracted to have tried the new version, but I'll get to it
RSN. Just wanted to let you know that the "color" problem was probably
mine...

More later,
Frank

I'm always told how SSE2 routines always beat the FPU's hard coded routines,
however i've never actually seen this quantified. Yes, SIMD is good in theory,
but can it really beat scalar routines? It uses more memory (more instructions
streamed), and it's not hard coded. I've seen some C code trying to quantify
this, but naturally the speed gain presented has not only been inconsistent (I
assume the fault is in failing to consider the task scheduler), but the gain
seems less than 10% every time for the functions that i feel matter the most
(fsincos and atan). More so, I've found some code that is theoretically faster
than a nice Taylor, and seems pretty accurate when i typed in the function on my
TI-NSpire. I was wondering if anyone had any code laying around that they use to
benchmark procedures while taking the schedualer out of the equation. It might
also help the community in the event that they do not have a benchmarker handy
to try other things.

Hi All,
The web page now has downloads in "deb" and "rpm" formats.

I still need to verify each download by installing here.
That might take awhile, it was a surprise to find that
the total number of download files is 110.  Don't know
where all those files came from.

Hopefully, the new deb and rpm formats will make
it easier to some users to get the tools working.  I
prefer the tar.gz format myself, but not everyone likes
to look at the source files.

all the best, jeff

On Wednesday 08 April 2009 16:50:16 Frank Kotler wrote:

> I did just d/l the latest asmtools, and started in the AsmLib_tutor
> directory. Immediately had trouble. When I hit F3 to compile, I got
> error messages from ld about "can't find _start". The resulting
> executable gets "cannot execute binary file", or with F4 in asmide,
> minibug returns immediately (silently). The problem seems to be that
> Nasm is being asked to assemble the wrong file: "asmlib_display_demo1.3
>    [14" or so (this exists, but zero-length). I think the problem's in
> the makefile(?). I'm seeing something like:

Great, a bug to work on!!  I needed a break from administration
stuff.

The problem was a buffer overflow.  Old memory conservation
habits die hard.  I fixed it and uploaded a new AsmIDE to web page.
It is now version 4
http://linuxasmtoos.net

> ext = 3�[14~
> I'm not familiar with the syntax. Is that correct?

If you see it again, we can call it a feature.  Maybe the
GNU folks will modify their development tools to accept
it.  Eventually, it might get to the NSA folks and they will
think it a secret code.  That should add some activity
to this list.

> Assembling and linking "by hand" with the same command-lines works fine.
> Having done so, and restarting asmide, F4 starts up minibug, but
> stepping through it, the display is strange - seems like only the middle
> few lines are scrolling(?). The instruction I'm about to step through
> doesn't seem to be displaying(???).

Whoa??? I was not able to reproduce this.  One problem might
be my color selection for the current instruction at EIP.  On my
system it is a light bar for the background and a slightly darker
color for the forground text.  On other monitors in may be a
problem???

> keep gettin' distracted! (Adult Attention Deficit Hypo-Activity
> Disorder...)

Is that related to FQLC (Forget Quality, Lets Code!)?   I have suffered
from FQLC for about 50 years.

In the spirit of AADHAD here are some totally unrelated random thoughts:

  1. I just discovered the program "weex" to upload web pages.  It might
     be of interest if your host only allows standart FTP uploads.  "weex"
     does not confuse easily and is easy to use.

  2. After much study of creating .deb and .RPM files, along came an
      amazing program called "checkinstall".  It watches the install of
      a tar.gz file and then builds .deb or .rpm packages.  That's it, no
      work required.  The source file for checkinstall has a neat trick,
      It watches its own install and creates a .deb or rpm for future
      installs or uninstalls.


all the best, jeff

jeff wrote:
>
>
> Hi All,
> The web page has another mini howto for
> getting CPU information. Also, I've updated
> AsmFile, AsmBug, and possibly others.
>
> If anyone is intersted in a howto for setting up
> xterm, let me know. I've collected a small
> stack of changes and techniques.
>
> http://linuxasmtools.net <http://linuxasmtools.net>

You are a *dynamo*, Jeff!!! I can't come close to keeping up with you.

I did just d/l the latest asmtools, and started in the AsmLib_tutor
directory. Immediately had trouble. When I hit F3 to compile, I got
error messages from ld about "can't find _start". The resulting
executable gets "cannot execute binary file", or with F4 in asmide,
minibug returns immediately (silently). The problem seems to be that
Nasm is being asked to assemble the wrong file: "asmlib_display_demo1.3
    [14" or so (this exists, but zero-length). I think the problem's in
the makefile(?). I'm seeing something like:

ext = 3�[14~

I'm not familiar with the syntax. Is that correct?

Assembling and linking "by hand" with the same command-lines works fine.
Having done so, and restarting asmide, F4 starts up minibug, but
stepping through it, the display is strange - seems like only the middle
few lines are scrolling(?). The instruction I'm about to step through
doesn't seem to be displaying(???).

Sorry to be always lodging complaints. Looking forward to getting into
more of your stuff. The CMOS stuff looks interesting - I didn't know we
could do that! And I never followed up on learning about signals... I
keep gettin' distracted! (Adult Attention Deficit Hypo-Activity Disorder...)

Best,
Frank

Hi All,
The web page has another mini howto for
getting CPU information.  Also, I've updated
AsmFile, AsmBug, and possibly others.

If anyone is intersted in a howto for setting up
xterm, let me know.  I've collected a small
stack of changes and techniques.

   http://linuxasmtools.net

all the best, jeff