Incompatibility of GCC asm std with ncurses

Alan5 · 09-19-2011, 04:37 PM

Using gcc compiling with ncurses there is an incompatibilty. I am surprised by this and I hope someone can assure me that this is known, and my compiler is out of date.

The problem comes with the use of " std ;" , with "%cc" in the clobber list.

For a Linux window this compiles and runs correctly. Compiled for a ncurses window at execution this crashes, usually reporting Segmentation fault , sometimes Floating point exception.

This is easy to workaround, " pushf ;" at the start and " popf ;" at the end of each section of assembler code compiles and runs perfectly and without the need for "%cc". So after a couple of troubled weeks I have no problem.

But I am amazed, how can it happen ?

My system is a standard PC with 32 bit pentium under Ubuntu.

tuxdev · 09-19-2011, 04:43 PM

With no real idea what's wrong without code, I'd recommend not using the asm keyword and throwing the code into a separate file with a standalone function.

Alan5 · 09-20-2011, 03:55 AM

Many thanks tuxdev.

I found the problem in some work that I am completing, comprising about 140 kbytes of c . I found the guilty parts and then produced a short piece using just these, and the failure disappeared.

On reflection I doubt that ncurses has any hand in the matter other than applying a bit of stress to faulty code that tests it to destruction.

I suspect that "%cc" was incorrect, it should be "cc" . I will confirm this later,

Alan5 · 09-20-2011, 11:33 AM

Brennan quotes "cc" for the clobber list, and says that he rarely uses it because it is unnecessary. He gives no example.

"%cc" and "cc" both compile silently.

And neither work to prevent a crash when compiling for ncurses.

The acronym, cc , is unsettling. Why is there no f in it ? So is it right ?

If for every asm section that starts with std I finish with " cld ;" then good behaviour is maintained.

But I will use " pushf ;" and " popf ;" because whatever is wrong, that is impregnable.

Although I began to doubt my first post, I am back to the opinion that something is wrong.

My work is here : http://sourceforge.net/projects/bignlibacbignum/files/ . The main download gives all c and a manual. The asm folder contains bignGCC.lib , which is equivalent to the all c version with ten short sections of inner loops as assembler. There is the old faulty file there now. I will post a fireproof version alongside it within a couple of hours. If anyone wishes to compile and run then you will need the collection in the tar.gz .

Alan5 · 09-20-2011, 03:43 PM

Sorry, I am not ready to put up a good quality file containing good assembler because I have broken something and I don't know what.

It should be repaired and available in 24 hours from the this post.

Alan5 · 09-21-2011, 03:10 PM

I have posted files at http://sourceforge.net/projects/bign...num/files/asm/ .

Come up one level to find the main download.

This demonstrates that "cc" in the clobber list does not work.

I will be grateful for advice.

And my thanks for your interest.

Alan5 · 09-22-2011, 02:18 PM

I have prepared a document briefly describing the problem. It is a text file as here :-

Code:

ccfail.txt
==========

This reports details my problem in GCC using assembler, the acronym cc in the
clobber list may fail when used with ncurses .

Background
==========

For about twelve years I have tinkered with a c library for multi element
mathematics, just like miracl and gmp . I did it because I enjoyed it.

The library self adjusts for 16 or 32 bit compilation. I will quickly add the
option of 64 bits as soon as someone offers to test developments.

It self adjusts to work with compilers that use long or long long data types.

It is feature rich. I find variations interesting even if they are not useful.

The object was pleasure, mine and any interested user's.

I published that on SourceForge in 2009 , and revisions since then.

The essential files of the c library are
========================================

bign.lib	file of elemental maths functions

big_acc.lib	optional accessories providing square root and forward and
		reverse log and trig

bigcalc.c	testbed and demonstrator
					       _
dosface.h	interface with MS_DOS		|
						|  these permit fixed display
coniface.h	interface with conio.h		|- with single key operation
						|
ncurface.h	interface with ncurses	       _|

pix.txt		pi

big_e.txt	e

buserdoc.html	documentation for a user

Options
=======

I offer several options. These are relevant.

Trace which reports activity onto a chosed stream, by default stdout .

Ommission of decimal conversion.

Assembler
=========

These five activities in bign.lib contain inner loops that take most of the
processing time : big on big multiply, big into big divide, int on big multiply,
int into big divide and big shift up.

For tidiness I included shift down in the list for symmetry, and because it
would be quick to write converting from shift up.

These were initially written in Windows using DJGPP , successfully. They work with
MS-DOS and with a conio.h screen.

ncurses
=======

I converted to Linux a year ago. I wrote ncurface.h . This was wholly
successful in a ncurses window using bign.lib , that is all c with all options.

I like my interface files, they are now a separate project on SF .

Problem
=======

Compiling for ncurses with bignGCC.lib , that is with assembler, and with the
trace option enabled it fails. There are two failures : within the printf text
argument the operators \r and \t become newlines. During arithmetic the
program will immediately crash reporting usually Segmentation fault or Floating
point exception .

If any one of the components ncurses , trace or assembler are not used than the
material compiles and runs without fault.

I created a file where I could switch separate functions between c and
assembler. By testing using each function alone as assembler I found that the
failure occurs in the int into big divide and the shift up. These two operations
alone work by progressing down the big number array, the direction flag is set
with std .

I made a small c program containing the divide and shift with constant
trace reporting. In ncurses it runs perfectly. So that is not a way forward.

I experimented using "cc" or "%cc" in the clobber list. Brennan instructs "cc" .
Neither worked.

Working solution
================

I have rewritten bignGCC.lib .

At the start of each section of assembler I push the flags and pop them at the
end. There is no reference to flags in the clobber list.

This is entirely successful.

If a user defines the macro USE_CC then the int into big divide loses its
push and pop , and gains "cc" in the clobber list. This fails.

Discussion
==========

I have worked hard to be sure that there is no fault in my code. Possibly
without success.

Brennan says that he rarely uses "cc" in the clobber list. That is odd because
most sections of code set and reset flags. Because he gets away with it I
suggest that most compilation by GCC assumes that flags need initialising,
especially if they are to be read before being set. Except one that I have
discovered.

I have tried to compile to an assembler listing with -S , it delivered an
executable. With USE_CC defined it ran perfectly, that is without the failure as
described above.

Conclusion
==========

I think there are still three possibilies

1	my code contains a fault

2	Brennan is wrong instructing that "cc" reports flag use

3	there is a deep fault in GCC and or ncurses

Alan Firminger
22 September 2011

Alan5 · 09-24-2011, 05:46 AM

This post was my error, I apologize. It carried a failing program which I have edited away.

I forgot the essential initscr ( ) ; and endwin ( ) ; .

I am still stuck with a big problem.