I/O

I/O

[Rafael Diniz]

Hello all,
I'm using the sys_read to read chars from keyboard but I would like to read 
the key as the user type the key, and not wait for the enter command to read 
the char.
What's the best solution to this problem?

Thanks,
Rafael Diniz

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Engenharia da Computação  --  Unicamp
http://www.gnu.org/philosophy/why-free.pt.html
Usuário do sistema operacional GNU/Linux
Chave PGP: http://www.dcc.unicamp.br/~ra017126/pubkey.asc
"Acreditar num conhecimento que pode ser vendido e
comprado é uma forma sutil (e cruel) de perpetuar a ignorância."
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I/O

[Rudolf Marek]

Hello,

you have to change the TERMIO setting via IOCTL syscall.

(I think ICANON, see manual: man termios)

http://linuxassembly.org/asmutils/asmutils-0.17.tar.gz

look at sh.asm for example how to change the terminal (i think the
routine is called smth like term_setup, it is called at startup )

I hope this will help you.

Regards

Rudolf


On Thu, 11 Sep 2003, 
Rafael Diniz wrote:

> Date: Thu, 11 Sep 2003 08:01:37 -0300
> From: Rafael Diniz <rafael.diniz@ic.unicamp.br>
> To: linux-assembly@vger.kernel.org
> Subject: I/O
> 
> Hello all,
I'm using the sys_read to read chars from keyboard but I would like to read 
the key as the user type the key, and not wait for the enter command to read 
the char.
What's the best solution to this problem?

Thanks,
Rafael Diniz

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Engenharia da Computação  --  Unicamp
http://www.gnu.org/philosophy/why-free.pt.html
Usuário do sistema operacional GNU/Linux
Chave PGP: http://www.dcc.unicamp.br/~ra017126/pubkey.asc
"Acreditar num conhecimento que pode ser vendido e
comprado é uma forma sutil (e cruel) de perpetuar a ignorância."
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I/O

[peter w krause]

Rafael Diniz am Donnerstag, 11. September 2003 12:01:
> Hello all,
> I'm using the sys_read to read chars from keyboard but I would like to read
> the key as the user type the key, and not wait for the enter command to
> read the char.
> What's the best solution to this problem?
			^^^^^^^^^^^^ -?- 
my solution:

ioctl TCGETS		get and save current state into memory
fcntl F_GETFL		read channel flags to ecx
fcntl F_SETFL		with ecx as just read
ioctl TCSETSW		set non-canonical mode
		....		do the program
fcntl F_SETFL		restore channel flags
ioctl TCSETSW		restore i/o mode
		ret

examples from F4 source, file <inikernel.S>, att syntax,
	http://www.lxhp.in-berlin.de/lhpf4.html
(nasm syntax examples in 'lib4th', file <l4sys.inc>
	http://www.lxhp.in-berlin.de/lhpf8.html )

// set 'stdin' to non-blockin r/w mode
inonbl:	pushal
		pushal
		movl $stdin,ebx
// file descriptor
 		movl $F_GETFL,ecx
// read the i/o flags
// in case of modification of a re-useable device (console, &c)
// some code should now store the i/o flags for later restauration
		sys_ fcntl
		andl $~(O_WRONLY|O_RDONLY|O_RDWR|O_NONBLOCK|O_SYNC),TS
// clr flag-bits
		orl $(O_RDWR|O_NONBLOCK),eax
// modify to non-blocking and r/w
		movl eax,edx
		movl $F_SETFL,ecx
		sys_ fcntl
 // write modified i/o flags
		popal
 		ret 

// get 'stdout' tty description
gettattr:	pushal
		leal tattrv,edx
		movl $TCGETS,ecx
		sys_ ioctl
// fetch stdin vt state for rst on exit
		cmpl $maxerr,eax
// error if ret EAX unsigned greater than 0xfffff000
		jnc 2f
// again, but saved for later restauration of console state
		leal stattv,edx
 		sys_ ioctl
 		cmpl $maxerr,eax
2:		popal
		ret                                                                                                                              

// set 'canonical' i/o mode,  have the default data in memory at <tattrv>
vtini:	pushal
		movl $stdin,ebx
// store the rsp file descriptor to reg EBX
		leal tattrv,edx
		movl $TCSETSW,ecx
 		andl $~(ICANON|ECHO),termios_c_lflag(edx)
// leave sigs enabled, disable erase/fill processing, echo
		orl $ONLCR,termios_c_oflag(edx)
// enabling NL<-CR/NL                                                                   
		andl $~(INPCK|ISTRIP|IXON),termios_c_iflag(edx)
// 8bit chars
 		movb $NVTIME,termios_c_cc+VTIME(edx)
// timeout * 1/10 s (if ~ICANON)
  		movb $NVMIN,termios_c_cc+VMIN(edx)
 // min chars per read opr, EAGAIN from sys_read only if NVMIN=0
		sys_ ioctl
 // set new tty mode                                                                                      
 		popal                                                                                                                            
  		ret                                                                                   

sys_fcntl:		http://www.lxhp.in-berlin.de/lhpsysc1.html#fcntl
				http://www.lxhp.in-berlin.de/lhpfcntl.html
sys_ioctl:		http://www.lxhp.in-berlin.de/lhpsysc1.html#ioctl
				http://www.lxhp.in-berlin.de/lhpioctl.html#tty_ioctl.c
termios structure:	http://www.lxhp.in-berlin.de/lhpstruc.html
manual page:	man 4 console_ioctls
info page:		info libc, node 'Noncanonical Input'

regards,
	hp
-- 
linux,asm,forth: http://www.lxhp.in-berlin.de/index-lx.shtml
pse, reply to  >> hp -at- lxhp -dot- in-berlin -dot- de <<

Assembler Tools

[jeff]

For the last year I've been struggling with
asm development tools and have put together
a combination that works.  Next, the plan is
to continue porting the DOS alib to Linux or
build a filemanger to complete the Assembler
tool package.

Anyway, is anyone interested in looking at
this?  It does symbolic debugging and
includes a editor with some syntax highlighting.
Basically, one can debug using the source
file and set breakpoints with mouse clicks.

The editor is written in assembler and can
be used as a base to create other editors.
Everything is table driven and it has commands
for simple windowing, macros, paragaphing,
user extensions, calculator, etc.

jeff

Re: Assembler Tools

[Rafael Diniz]

I would like to see this :-)

Bye,
Rafael Diniz

Em Seg 15 Set 2003 11:30, jeff escreveu:
> For the last year I've been struggling with
> asm development tools and have put together
> a combination that works.  Next, the plan is
> to continue porting the DOS alib to Linux or
> build a filemanger to complete the Assembler
> tool package.
>
> Anyway, is anyone interested in looking at
> this?  It does symbolic debugging and
> includes a editor with some syntax highlighting.
> Basically, one can debug using the source
> file and set breakpoints with mouse clicks.
>
> The editor is written in assembler and can
> be used as a base to create other editors.
> Everything is table driven and it has commands
> for simple windowing, macros, paragaphing,
> user extensions, calculator, etc.
>
> jeff

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Engenharia da Computação  --  Unicamp
http://www.gnu.org/philosophy/why-free.pt.html
Usuário do sistema operacional GNU/Linux
Chave PGP: http://www.dcc.unicamp.br/~ra017126/pubkey.asc
"Acreditar num conhecimento que pode ser vendido e
comprado é uma forma sutil (e cruel) de perpetuar a ignorância."
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Does anyone code in assembler today?

[jeff]

I guess most programmers work in Java one of the
newer object oriented languages.   Or maybe
Linux is not ideal for assembler and the few remaining
coders use other platforms?

The level of activity on this list and others indicate
the assembler community is not very active.   That
is one indicator.  Another is the number of people
interested in new programs.  Ten years ago when
i released a program, a large number of people
jumped on it to look at the code.  My release of a
few days ago resulted in three responses.

So.. maybe we are a small community which is
difficult to join?  That's OK, there is always a niche
for small fast code and as systems mature the
competition moves from features to speed. 

I think this happened to some extent with DOS.  Once
it matured the companies needed something new to
sell.  They had a problem with the competition building
fast programs optimized in .asm.  This happened with
spreadsheets and other programs.

Of course, the argument is that hardware is getting faster
and speed is no longer an issue.  Also, memory is cheap
and big bloated programs are best because they get into the
market quickly.  It is much easier to train programmers
in the newer languages and todays tools isolates everyone
from knowing much about hardware or hex.

So.. i wonder if it would be better to port some old DOS
libraries to work under X or stay with the console?  I see
some asm activity in graphics and games.  There is also
the embedded linux area...

 jeff (looking for an interesting asm project)

Does anyone code in assembler today?

[myrkraverk]

Hi,

Well, for my part I'm programming assembly in Linux *on my PlayStation
2* so most of the discussion here simply doesn't apply to me.  I don't
have an intel processor -- nor do I know how to assembly one.

NOTE TO THE CURIOUS: Before asking about Linux and PlayStation 2 or
making any sort of remarks, please check playstation2-linux.com
first.  Funny remarks are funny -- once!

So most of what goes on on this list is simply noise to me -- but if
you're looking for application of assembly programming the PlayStation
2 is deffiently a good one.  Most commercial games are written in
combination of C/C++ and assembly, and -- afaik -- there's no compiler
for the vector processing units.


Johann

P.S.	Sorry for bad posting style, but this really isn't a Q/A mail.

jeff writes:
 > I guess most programmers work in Java one of the
 > newer object oriented languages.   Or maybe
 > Linux is not ideal for assembler and the few remaining
 > coders use other platforms?
 > 
 > The level of activity on this list and others indicate
 > the assembler community is not very active.   That
 > is one indicator.  Another is the number of people
 > interested in new programs.  Ten years ago when
 > i released a program, a large number of people
 > jumped on it to look at the code.  My release of a
 > few days ago resulted in three responses.
 > 
 > So.. maybe we are a small community which is
 > difficult to join?  That's OK, there is always a niche
 > for small fast code and as systems mature the
 > competition moves from features to speed. 
 > 
 > I think this happened to some extent with DOS.  Once
 > it matured the companies needed something new to
 > sell.  They had a problem with the competition building
 > fast programs optimized in .asm.  This happened with
 > spreadsheets and other programs.
 > 
 > Of course, the argument is that hardware is getting faster
 > and speed is no longer an issue.  Also, memory is cheap
 > and big bloated programs are best because they get into the
 > market quickly.  It is much easier to train programmers
 > in the newer languages and todays tools isolates everyone
 > from knowing much about hardware or hex.
 > 
 > So.. i wonder if it would be better to port some old DOS
 > libraries to work under X or stay with the console?  I see
 > some asm activity in graphics and games.  There is also
 > the embedded linux area...
 > 
 >  jeff (looking for an interesting asm project)
 > 
 > 
 > -
 > To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sometimes I do not think at all!  Does that mean I don't exist
in the mean time?

Re: Does anyone code in assembler today?

[Frederic Marmond]

Hi all,
In my work, I don't code all days in assembly, but I made some work with 
it (our own linux loader, some inline assembly, lot of debugging, ...)
I'm sad to say that assembly is baddly considered by most of 'new' 
programmers, who don't know anything about how a computer is made, but 
only know programming products (they know where to click to make their 
graphical project generate code and compile).

For those who want to work (a little) in assembly, I can suggest them to 
find a company that use/debug/write drivers. Lot of drivers are in C, 
but we still can find some that need assembly for performance or small 
code (the main goal for all embeded systems.)
The other way to do assembly is to find a company that use buggy drivers 
;-), or who port drivers from an arch to an other, or who don't have 
sources of it, ...

But I don't think assembly may be used for a 'real soft' other than just 
parts of a lib or driver... :-(
This good old time is now deprecated ;)

Fred


jeff wrote:

>I guess most programmers work in Java one of the
>newer object oriented languages.   Or maybe
>Linux is not ideal for assembler and the few remaining
>coders use other platforms?
>
>The level of activity on this list and others indicate
>the assembler community is not very active.   That
>is one indicator.  Another is the number of people
>interested in new programs.  Ten years ago when
>i released a program, a large number of people
>jumped on it to look at the code.  My release of a
>few days ago resulted in three responses.
>
>So.. maybe we are a small community which is
>difficult to join?  That's OK, there is always a niche
>for small fast code and as systems mature the
>competition moves from features to speed. 
>
>I think this happened to some extent with DOS.  Once
>it matured the companies needed something new to
>sell.  They had a problem with the competition building
>fast programs optimized in .asm.  This happened with
>spreadsheets and other programs.
>
>Of course, the argument is that hardware is getting faster
>and speed is no longer an issue.  Also, memory is cheap
>and big bloated programs are best because they get into the
>market quickly.  It is much easier to train programmers
>in the newer languages and todays tools isolates everyone
>from knowing much about hardware or hex.
>
>So.. i wonder if it would be better to port some old DOS
>libraries to work under X or stay with the console?  I see
>some asm activity in graphics and games.  There is also
>the embedded linux area...
>
> jeff (looking for an interesting asm project)
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Re: Does anyone code in assembler today?

[peter w krause]

Frederic Marmond am Donnerstag, 18. September 2003 07:31:
	[...]
>
> But I don't think assembly may be used for a 'real soft' other than just
> parts of a lib or driver... :-(
> This good old time is now deprecated ;)

'embedded systems' (which is quite a bit)

hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml
  >> hp -at- lxhp -dot- in-berlin -dot- de <<

Re: Does anyone code in assembler today?

[peter w krause]

Frederic Marmond am Donnerstag, 18. September 2003 09:04:
> peter w krause wrote:
> >Frederic Marmond am Donnerstag, 18. September 2003 07:31:
> >	[...]
> >
> >>But I don't think assembly may be used for a 'real soft' other than just
> >>parts of a lib or driver... :-(
> >>This good old time is now deprecated ;)
> >
> >'embedded systems' (which is quite a bit)
> >hp
>
> hum...

so, that`s gone, too... ;)

hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml
  >> clf -at- lxhp -dot- in-berlin -dot- de <<

Re: Does anyone code in assembler today?

[jeff]

On Wednesday 17 September 2003 11:31 pm, Frederic Marmond wrote:
> I'm sad to say that assembly is baddly considered by most of 'new'
> programmers,

I think this is true of assembler programmers also.  Some think it is
difficult and use it for small projects.  Other programmers
find it easy and use it for big projects.

This difference is interesting.  What makes assembler useful
for some programmers and of limited use for others?  I know some
of the answers but it is a complicated question.  Here are some
facts that look accurate to me:

1. Assembly can easily turn into a nightmare of spaghetti
    code.  This requires functions and modules to be created
    carefully and at lower levels than other languages.
2. Most Assembler tools are awful and new programmers have
    not encountered good tools.
3. People are different and some people do not want to think
    about registers and such.
4. It is easy to make assembler difficult for others to understand.
   The use of macros and uncommented subroutines soon create a
    language only readable by the original programmer.
5. A good assembler library can make coding speed and results about
    the same as a high level language.  Now, this point will probably
    create some argument.  About the only way to prove it would be
    to have some timed trials.  I've done a few over the years and
    found it true but creating the library in the first place was a big job.
    
   It is interesting we now have thousands of languages and still people
   are working on new languages.  All these languages are not much different
   from assembler with different libraries.

Anyway, I found assembler under Linux to be a nighmare at first.  The tools
were awful and the documentation was scattered around and written for
"c" programmers.  Now, with kdbg and a working nasm things are better
but could be improved.  It would be nice to have a good editor that recognized
conditional statements and could show the code of interest.  I don't really
want to see code for Sun or AIX systems.  

Has anyone tried the new nasm 98.38 that was just released to fix ELF
problems.   It appears to still have the old problem of stuffing a zero in
the generated code.  Probably a memory leak in the "c" code.

I wonder if we keep creating new languages and tools if someday our
tools will become more complicated than the thing we are tying to code.
Today we have all these different ways of doing "make" files and
organizing projects.  Communication tools for programmers working
on the same project and tools to release programs.  Our source code
is full of conditional macros to support all the various flavors of UNIX.
We have thousands of languages.  On and on.. 

jeff (still looking for a asm project)

Re: Does anyone code in assembler today?

[Maciej Hrebien]

jeff wrote:
> 
> On Wednesday 17 September 2003 11:31 pm, Frederic Marmond wrote:
> > I'm sad to say that assembly is baddly considered by most of 'new'
> > programmers,
> 
> I think this is true of assembler programmers also.  Some think it is
> difficult and use it for small projects.  Other programmers
> find it easy and use it for big projects.
> 
> This difference is interesting.  What makes assembler useful
> for some programmers and of limited use for others?  I know some
> of the answers but it is a complicated question.  Here are some
> facts that look accurate to me:
> 
> 1. Assembly can easily turn into a nightmare of spaghetti
>     code.  This requires functions and modules to be created
>     carefully and at lower levels than other languages.
> 2. Most Assembler tools are awful and new programmers have
>     not encountered good tools.
> 3. People are different and some people do not want to think
>     about registers and such.
> 4. It is easy to make assembler difficult for others to understand.
>    The use of macros and uncommented subroutines soon create a
>     language only readable by the original programmer.
> 5. A good assembler library can make coding speed and results about
>     the same as a high level language.  Now, this point will probably
>     create some argument.  About the only way to prove it would be
>     to have some timed trials.  I've done a few over the years and
>     found it true but creating the library in the first place was a big job.
> 
>    It is interesting we now have thousands of languages and still people
>    are working on new languages.  All these languages are not much different
>    from assembler with different libraries.

[ cut ]

All you say is true. With comparition to HLLs assembly is more
powerfull, flexible, not generalized like all HLLs, gives you more
control on code the cpu is executing, so any speed/size optimizations
can take place. It gives you possibility to use some special units of
cpu or the computer system as a whole. Generalizing: it makes possible
to use all features the computer system can offer & control them as you
wish.

I think people turn into assembly only if they want such power, they
want to know exactly what's going on & want to have control in details,
sometimes bit-details. Of course not even mention cases where assembly
is the only way to do the job.

Yes, people are diffrent & they "talk" in diffrent languages. Some of
them like more hardware focus in daily coding but some are focused only
on their data structures & algorithms and want to think only in
genaralized way without wondering what cpu will run their algorithms &
how it achieve this.

So there is another reason why more poeple stay in HLLs: they just want
their code to be more portable/machine independent & HLLs like ie. C
gives you (more or less) this advantage.

If we talk about generalization & bits, look at this very simple
example:

const bool carry = x&(1<<(sizeof(x)*8-1));
x = (x<<1)|carry;

Yes, it's simple rol. But look what a compiler will (possibly) generate:

lea (%eax,%eax),%ebx
shr $31,%eax
or %ebx,%eax

not just: rol $1,%eax. Comment it by yourself, in your language.. ;)

Yes, some tools are awful but don't forget we are mammals - we are
getting used to while using this tools more & more.. ;)

Regards,

-- 
Maciej Hrebien

Re: Does anyone code in assembler today?

[Stephen Satchell]

At 12:19 PM 9/21/2003 +0200, Maciej Hrebien wrote:
>All you say is true. With comparition to HLLs assembly is more
>powerfull, flexible, not generalized like all HLLs, gives you more
>control on code the cpu is executing, so any speed/size optimizations
>can take place. It gives you possibility to use some special units of
>cpu or the computer system as a whole. Generalizing: it makes possible
>to use all features the computer system can offer & control them as you
>wish.
>
>I think people turn into assembly only if they want such power, they
>want to know exactly what's going on & want to have control in details,
>sometimes bit-details. Of course not even mention cases where assembly
>is the only way to do the job.
>
>Yes, people are diffrent & they "talk" in diffrent languages. Some of
>them like more hardware focus in daily coding but some are focused only
>on their data structures & algorithms and want to think only in
>genaralized way without wondering what cpu will run their algorithms &
>how it achieve this.
>
>So there is another reason why more poeple stay in HLLs: they just want
>their code to be more portable/machine independent & HLLs like ie. C
>gives you (more or less) this advantage.

I'm afraid I can't agree with you.  The focus of my disagreement revolves 
around maintainability, optimization, and bug avoidance.

Last thing first:  bug avoidance.  Coding style guides help tame many 
classes of typo-bugs in assembler more so than in HLLs, but the brain-fart 
bugs are there just the same, only more subtle in assembler than in 
HLLs.  From a productivity standpoint, then, assembler has little to 
recommend it.  With the power of processors today, the old 80/20 rule still 
applies, but more and more you see eight lines of assembler here, a couple 
of lines there, and only after much profiling to show a significant 
gain.  For an example, see the TCP/IP stack code, and the hand-coding of 
crc calculations in the various architectures -- but the base C code is 
still in the source.

Maintainability:  Ignoring for the moment the shrinkage of good assembler 
programmers, there is the issue of maintaining the code long-term.  I have 
a hunk of assembler code that lasted over 10 years in the Intel/MS-DOS 
world...and it finally fell so behind the advances in architecture that I 
dumped it a couple of years ago in favor of an HLL implementation that ran 
faster, was more reliable, and allowed a more general API to other 
code.  By hand, it would have been a bitch to convert to 32-bit.  Assembler 
coders are going to face the same thing in their code when they try to move 
to 64 bits.

Finally, optimization.  The rules for code optimization have grown so 
bizarre that a human being has great trouble keeping track of who does what 
to whom in the course of several thousand lines of code.  The penalties 
vary by architecture:  in CISC you have merely a time penalty (assuming the 
chip doesn't have any mistakes in resource tracking); in RISC you have an 
incorrectly running program if you break the timing rules.  The fact is, 
any computer does a MUCH better job of tracking this sort of stuff than 
your average human being.  So let the computer do what computers are good 
for:  bookkeeping.

Which points up the potential need (see below, though) for something I once 
worked on:  an intermediate language that falls somewhere between HLLs and 
machine code.  The one I developed looked something like a jazzed-up 
P-Code, in which I define atomic operations with symbolic linkages , and 
let a code generator figure out how to generate code to implement the 
atomic operations and shuffle the result to make the most of whatever chip 
is being targeted.

Because I was using the gcc back-end, the language tended to be 
architecture-agnostic -- there were dialects to deal with register 
machines, stack machines, and RISCs.  The quality of the code generated, 
when compared with hand-coded "pure" assembler, was comparable, but the 
algorithms were more maintainable because one didn't have to worry about 
"the timing rules" to get time-optimized code.

The result wasn't salable, so there was no point to continue with the 
experiment when funds dried up.

Satch



Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra

Re: Does anyone code in assembler today?

[peter w krause]

I love that sentence (ex 'a.html'):
	The best part was being able to view comments in the
	source file.  Us old brain dead programmers need all
	the help we can get and without comments we go around
	in big circles.

jeff am Donnerstag, 18. September 2003 17:10:
> On Wednesday 17 September 2003 11:31 pm, Frederic Marmond wrote:

> 2. Most Assembler tools are awful and new programmers have
>     not encountered good tools.

sic. even for the tiny ZX81 there were better tools.

> 3. People are different and some people do not want to think
							^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     about registers and such.

first part applies.

> 4. It is easy to make assembler difficult for others to understand.

as is for "C", and "C++" even more and, some take that for 'complexity' which, 
due to lack of understanding soon gets the fame of being something 
valuable...

it is easy, as well, to make any prgram code (fairly) easy to understand, but 
would those readers then honour the utmost brillance of the rsp coder... ?!


> 5. A good assembler library can make coding speed and results about
>     the same as a high level language.  Now, this point will probably

which is trivial and, was well known, in the 'ancient' days.

>
> Has anyone tried the new nasm 98.38 that was just released to fix ELF
> problems.   It appears to still have the old problem of stuffing a zero in
> the generated code.  Probably a memory leak in the "c" code.

nsm might be worth giving it a try, again, if they finally managed to fix 
those stupid problems with branch code size 'optimizing'. but, even if 
functional by now, I'd find half an hour - and even more! - of 'optimizing' 
passes for a 150K (stripped) binary completely inacceptable...
the macroes processing was inacceptably slow, as well.

I gave up because of falsly assembled ELF shared libraries code and that 
utterly stupid 'optimization' - both of which 'AS' manages well and, fastly!

by now, besides I don't really #like# it, 'cpp' plus 'as' fit my requirements 
much better than 'nasm'. plus, both are available in any linux distribution 
and their reliability is highly proven - with each and every linux C program.

> is full of conditional macros to support all the various flavors of UNIX.

C 'portability...
	is not much more than willingly narrowed consciousness.

>
> jeff (still looking for a asm project)

of what kind?
i.e, my current contribution is wrt Forth compilers/interpreters, only.

regards,
	hp
-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml
  >> xxxx -at- lxhp -dot- in-berlin -dot- de <<

Re: Does anyone code in assembler today?

[linuxassembly]

> My release of a few days ago resulted in three responses.

Could it be that few people use assembly language debuggers?

I've always been surprised at the number of people who talk about using one 
on this list.  I figured people didn't use them and debugged using other 
methods.  When I first started assembly I used DOS debug to debug things, 
but as soon as I used graphics modes it became useless, and so I learned 
new ways to debug.  Many of my programming mistakes are obvious as soon as 
I run the executable, and so I know exactly what to fix.  Others require 
tossing in a few print-type macro calls so that I can see what code is 
being executed and what isn't (I can leave these in the code, and enable or 
disable the macro when compiling).  Sometimes I use another macro to print 
out a register's contents.  I've got code that prints a register dump, so 
if I need to see a lot of registers I'll just insert a 'cli' or something 
that will segfault.  This code also keeps track of what functions are 
executing in a stack structure and prints it out (also can be disabled at 
compile time) and this about eliminates the need to track execution.  If 
things are really bad I'll write out a section of memory to a file and 
examine it with a hex editor, but that seldom happens.  I've just always 
debugged this way, and it's worked fine.  I really wouldn't know what to do 
with a debugger.

> So.. maybe we are a small community which is difficult to join?

It could be.  Assembly programmers look at my code and freak out over the 
vast number of macro calls and such, and declare it 'not real assembly'.  
Consider that anything to help you get started in assembly language is 
going to be written by these same people.

If you're debugging a piece of code that segfaults, it'll be quite easy to 
do this:

status "first"
mov eax, [ebx]
status "second"
mov edx, [ecx]
status "third"
div dword [ebp+12]
status "fourth"

If you run the code and it prints...

crap:/home/sloop/$ ./program
first
second
Segmentation Fault
crap:/home/sloop/$

...you pretty much know where to look for the problem.  Yet no one likes to 
use macros for anything.  People getting into assembly language are never 
introduced to using macros to simplify programming, and when you can't so 
much as write five lines of code without a mistake (common for beginners) 
adding in more code to debug it will likely just result in even more bugs.  
Beginners need to be encouraged to use macros, at least as a stepping stone 
to help them in the beginning.

But macros are good for everything.

http://www.evobsyniva.com/softer/archive/softer-118.tgz

file: /src/macros.nasm  - 63 macros, without which Softer wouldn't exist at 
all.

9 macros create if/then type statements, 6 for do/loop, and a skip/land 
(just jumps over a block of code) and they almost always produce the same 
code I would have written without them.  There are a couple cases they 
won't, usually I use them anyway because they do one very important thing:  
they keep the code readable.  When you've got a hundred different branches 
in a piece of code, it's impossible to give them all a meaningful label, 
and you can't look at a jump instruction and tell if it goes forwards or 
backwards, and how far.  When you use if/elseif/else/endif, you just follow 
the indenting and there's your answer.

Case in point:  /pjasm/*.asm
I wanted to write these in pure assembly language without any macros just 
for fun.  By the time I was finished I was having a heck of a time 
debugging them because I simply couldn't keep track of how they worked in 
my head.  Lack of indenting and nested code structures makes any 
programming language extremly difficult.  I couldn't follow code I wrote 
ten minutes earlier.

print 2, "yes, this macro does what you think"  -- when you're debugging 
you don't want to have to declare the string here, write code there to do 
the system call, and clean up the mess afterwards.

3 macros that read/write blocks of data fully checking system call return 
values, good for debugging and quick programs you'll only use once, I have 
the same code in functions in a different file if I plan to use it in a 
real program.

enter/leave macros.  These aren't the enter/leave instructions, I couldn't 
figure out what they did, so I made macros with the same name.  They work 
like ' enter "easy.asm - easyprint" ' and just db the string and call a 
function that adds the address of the string to a stack, leave pops the 
address off the stack.  When I get a register dump from a trap macro or a 
system signal, I get this:


Signal 11 recieved.

EAX: 00000000  EBX: 00000002  ECX: 08052455  EDX: 000002D4
ESI: BFFFFC50  EDI: 0805272A  EBP: BFFFFB44  ESP: BFFFFB24
EIP: 08048C30  EFLAGS: 00000000 00000000 00000010 00000110                  
                                                                  ..OD   SZ 
A P C
Debugging Stack:

Softer 0.118
startup.asm
 -- framebuffer check
easy.asm - easyprint
!!! Signal Trap

Happy debugging!

Under the section "Debugging Stack"  "Softer 0.118" is the main.asm file 
that starts the program.  It called startup.asm which was in the middle of 
the framebuffer check when it called easy.asm's easyprint function.  At 
this point a signal 11 was recieved (see top line), and thus we got this 
error message.

It'd have been impractical without macros.  I'd just have a segmentation 
fault message and have to guess where the problem was.

Now to assembly language itself.  Why do we only allow one instruction on a 
line of code?  Take the example below for example.  Once you read the 
contents of the first if section, you basically know what the next three 
do, since you can easily see they're at least almost the same.  Do this one 
instruction on a line and you can't even fit it all on the screen.  You 
also have one long stream of code all of which basically looks the same 
except for a blank line here and there, but like this it has a certain 
shape that can be recognized at sight, making this function easier to find 
in a file.

The third line, all three instructions work towards a single goal, it makes 
sense to group them together.  The fifth line all six instructions select 
the correct video page, makes sense to group them as well.

softer_outof_video
  # Save Softer's video in RAM.
  mov ebx, [display_mode]; shl ebx, 4; add ebx, ram_counts
  if dword [ebx+0], 0, nz
    mov dx, $3CE; mov al, $04; outb; mov dx, $3CF; mov al, $00; outb;
    mov edi, softer_mem_store + $00000; mov esi, [video_ram_pointer]
    mov ecx, [ebx+0]; rep; movsd
  endif
  if dword [ebx+4], 0, nz
    mov dx, $3CE; mov al, $04; outb; mov dx, $3CF; mov al, $01; outb;
    mov edi, softer_mem_store + $10000; mov esi, [video_ram_pointer]
    mov ecx, [ebx+4]; rep; movsd
  endif
 if dword [ebx+8], 0, nz
    mov dx, $3CE; mov al, $04; outb; mov dx, $3CF; mov al, $02; outb;
    mov edi, softer_mem_store + $20000; mov esi, [video_ram_pointer]
    mov ecx, [ebx+8]; rep; movsd
  endif
  if dword [ebx+12], 0, nz
    mov dx, $3CE; mov al, $04; outb; mov dx, $3CF; mov al, $03; outb;
    mov edi, softer_mem_store + $30000; mov esi, [video_ram_pointer]
    mov ecx, [ebx+12]; rep; movsd
  endif
ret

> Of course, the argument is that hardware is getting faster
> and speed is no longer an issue.  Also, memory is cheap
> and big bloated programs are best because they get into the
> market quickly.  It is much easier to train programmers
> in the newer languages and todays tools isolates everyone
> from knowing much about hardware or hex.

I never see large programs (compared to other non-assembly programs) 
written in assembly language.  In it's natural state, assembly isn't well 
suited for large projects.  There's the madness of 10,000 labels I 
mentioned earlier from every single control branch and little temporary 
variable.  Etremely long source files since every operation is broken down 
into 6 steps, each on it's own line.  Any large program has to be split 
into seperate files to be managable (scrolling down 18,000 lines to get to 
the function you're looking for just isn't acceptable), but with NASM, 
every variable shared between files has to be global'd in the one file and 
extern'd in the other, and seeing the associated compiler errors gets old 
after a while, as does starting a new source file and copy&pasting the 
externs over for every shared variable you're going to use.  Worse yet you 
can't global on the same line you declare the variable.

I fixed this kind of with /tools/vernix.pl..  You make your global varibles 
with code line "vernix global_variable" and when compiled, these lines are 
looked for..  The word vernix is macro'd to null so it doesn't affect NASM, 
and a header file is created for each source file which contains global 
statements for each vernix variable in that file, and extern statements for 
each vernix variable in all the other files but that one (if you extern a 
global nasm gets upset).  It works pretty well.

In the end, I've got assembly pretty easy so I can program in it, but the 
problem is that beginners have to go and duplicate all the work I did 
above.  I can see why people would look at assembly and think it's too 
difficult to be worth the effort put into it.

> So.. i wonder if it would be better to port some old DOS
> libraries to work under X or stay with the console?

Stay away from X.  Everyone secretly hates it, it's the only thing that 
makes them have to reboot their linux box.  If you just want to do VGA 
graphics modes Softer contains all the code you need to switch modes in 
src/video.asm, and the stuff you need to do because of this in console.asm, 
switcher.asm, signal.asm, keyboard.asm, ... most the other files.  It's 
complicated, you have to make up for Linux's lack of a VGA driver and do 
all the multitasking of the display device between your program and the 
other programs yourself.  But it's workable, I even figured out all the 
race conditions although one took me like a year.

BTW, I have screenshots now:  
http://www.evobsyniva.com/softer/captures.html  VGA modes in Linux are 
really quite nice, much nicer than GUI windows in X.

 

Art of Assembly Is Real!

[Randall Hyde]

Friday, Sept 12, I headed up to San Francisco
for an interview on TechTV about my book
"The Art of Assembly Language".
While I was there, the books arrived from the printers.
Yes, people, "The Art of Assembly Language" is *really*
available now.

As Border's, Amazon, etc., have put the book on hold
waiting for it to finally arrive, my suggestion is to go to
the publisher's web site (http://www.nostarch.com)
and get it there. They have a special offer right now on
the book (limited time offer, until the other on-line outfits
get their act together).
Cheers,
Randy Hyde

Re: Art of Assembly Is Real!

[Brien B.]

I have a book named this, but reading further, I realize it's not the same 
one. :-)

That's neat. Good job.

Brien

On Monday 15 September 2003 10:42 pm, Randall Hyde wrote:
> Friday, Sept 12, I headed up to San Francisco
> for an interview on TechTV about my book
> "The Art of Assembly Language".
> While I was there, the books arrived from the printers.
> Yes, people, "The Art of Assembly Language" is *really*
> available now.
>
> As Border's, Amazon, etc., have put the book on hold
> waiting for it to finally arrive, my suggestion is to go to
> the publisher's web site (http://www.nostarch.com)
> and get it there. They have a special offer right now on
> the book (limited time offer, until the other on-line outfits
> get their act together).
> Cheers,
> Randy Hyde
> -
> To unsubscribe from this list: send the line "unsubscribe linux-assembly"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html