Groups > comp.lang.forth > #38202 > unrolled thread

rhel 7 and kforth

Started by	krishna.myneni@ccreweb.org
First post	2015-04-15 11:20 -0700
Last post	2015-04-17 08:41 -0700
Articles	20 on this page of 101 — 12 participants

Back to article view | Back to comp.lang.forth

  rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 11:20 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 19:09 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:13 -0700
      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:55 -0700
        Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:08 +0000
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 05:29 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 07:07 -0700
              Re: rhel 7 and kforth franck.bensusan@gmail.com - 2015-04-16 07:44 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:14 -0700
            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 14:02 +0000
              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:12 -0700
        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 12:25 -0700
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:02 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:06 -0700
              Re: rhel 7 and kforth foxaudioresearch@gmail.com - 2015-04-16 17:24 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:39 -0700
                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 17:47 -0700
                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:44 -0700
                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:50 -0700
                      Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 19:10 -0700
                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 19:29 -0700
                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 20:10 -0700
                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:27 -0700
                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 02:04 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 11:41 +0000
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:45 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:01 +0000
                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:47 -0700
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:35 -0700
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 10:33 -0700
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 11:15 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 11:47 -0700
                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:51 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:41 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:42 -0700
                                              Re: rhel 7 and kforth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 09:02 -1000
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 10:53 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-05-03 17:22 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 10:23 +0000
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 00:10 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 17:45 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 13:08 +0000
                                  Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:27 +0000
                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:41 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:11 +0000
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 15:47 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:34 +0000
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-18 14:09 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:31 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:35 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:07 -0700
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:21 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 19:34 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 08:36 +0000
                                                    Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 11:36 +0000
                                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:29 +0000
                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:08 +0000
                                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-19 20:11 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 12:05 +0000
                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 01:27 +0200
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:18 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:00 +0000
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:28 -0700
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:34 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 21:07 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:41 +0000
                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-25 10:06 -0700
                                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 14:56 +0000
                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-26 20:22 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:02 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 03:59 -0700
                                                      Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 15:45 +0000
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:09 -0400
                                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:55 +0200
                                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:30 -0700
                                                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:44 -0700
                                                        Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 02:03 -0400
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 01:44 -0700
                                                            Re: rhel 7 and kforth Mark Wills <markwills1970@gmail.com> - 2015-04-28 02:44 -0700
                                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 16:47 -0700
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:00 -0700
                                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 17:14 -0700
                                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:59 -0700
                                                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 21:41 -0700
                                                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-29 03:07 +0200
                                                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 18:13 -0700
                                                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-29 00:07 +0000
                                                        Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 22:22 +0200
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 14:23 -0700
                                                            Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 23:51 +0200
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 16:50 -0700
                                                            Re: rhel 7 and kforth David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
                                                  Re: rhel 7 and kforth mhx@iae.nl - 2015-04-26 22:16 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:19 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 04:03 -0700
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:21 -0400
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:46 +0000
                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-23 16:46 +0200
                          Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:35 +0000
                            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:43 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:41 -0700

Page 1 of 6 [1] 2 3 4 5 6 Next page →

#38202 — rhel 7 and kforth

From	krishna.myneni@ccreweb.org
Date	2015-04-15 11:20 -0700
Subject	rhel 7 and kforth
Message-ID	<a6948250-7543-4540-b455-e1693be2806a@googlegroups.com>

I find that red hat enterprise linux, version 7, has broken 32-bit kforth. The number to string conversion, <# #S #>, produces gibberish. The Hayes core tests no longer pass for these words or for >NUMBER in rhel 7.

These words work under rhel 6, for both 64 and 32 bit versions (x86_64 and i686). RHEL 7 is provided only in 64 bit version. Something has likely broken in the 32 bit C libraries in rhel 7.

Krishna Myneni

[toc] | [next] | [standalone]

#38210

From	krishna.myneni@ccreweb.org
Date	2015-04-15 19:09 -0700
Message-ID	<95e8b4c8-6554-418f-b1b6-97aa56777103@googlegroups.com>
In reply to	#38202

On Wednesday, April 15, 2015 at 1:20:17 PM UTC-5, krishna...@ccreweb.org wrote:
> I find that red hat enterprise linux, version 7, has broken 32-bit kforth. The number to string conversion, <# #S #>, produces gibberish. The Hayes core tests no longer pass for these words or for >NUMBER in rhel 7.
> 
> These words work under rhel 6, for both 64 and 32 bit versions (x86_64 and i686). RHEL 7 is provided only in 64 bit version. Something has likely broken in the 32 bit C libraries in rhel 7.
> 

The test code to reproduce the problem is the Hayes core test file, found in the kforth distribution, under examples/system-test/core.4th

A simpler test is simply to do,

    1024 s>d <# #s #> type

One my RHEL7 system, this produces the nonsense "07". However, it works properly on my 64-bit fedora 21 system. It would be good to test the reproducibility of this problem on other RHEL7-derived distributions such as CentOS 7 and Scientific Linux 7.

Krishna

[toc] | [prev] | [next] | [standalone]

#38220

From	krishna.myneni@ccreweb.org
Date	2015-04-16 04:13 -0700
Message-ID	<6b95db78-ff4c-42aa-9680-7e4e588f61a4@googlegroups.com>
In reply to	#38202

On Wednesday, April 15, 2015 at 1:20:17 PM UTC-5, krishna...@ccreweb.org wrote:
> I find that red hat enterprise linux, version 7, has broken 32-bit kforth. The number to string conversion, <# #S #>, produces gibberish. The Hayes core tests no longer pass for these words or for >NUMBER in rhel 7.
> 
> These words work under rhel 6, for both 64 and 32 bit versions (x86_64 and i686). RHEL 7 is provided only in 64 bit version. Something has likely broken in the 32 bit C libraries in rhel 7.
> 


kforth version 1.5.2p1 (version 1.5.2 with update patches applied) appears to be broken in 64-bit fedora 21 as well.

While the Hayes core tests will show this, a simpler check is to do

1024 s>d <# #s #> type

I haven't come to any definite conclusions yet on the source of the problem.

Krishna

[toc] | [prev] | [next] | [standalone]

#38221

From	krishna.myneni@ccreweb.org
Date	2015-04-16 04:55 -0700
Message-ID	<fcc13b4b-8c59-4163-a15b-af0f419ab0be@googlegroups.com>
In reply to	#38220

On Thursday, April 16, 2015 at 6:13:26 AM UTC-5, krishna...@ccreweb.org wrote:
...
> I haven't come to any definite conclusions yet on the source of the problem.
...

One piece of code which appears to be broken is from the file, vmc.c. It is the implementation of the Forth word "#", shown below. The C function calls exported functions from the assembler file, vm.s. The assembly functions begin with "L_". The three assembler functions used in C_sharp() are L_utmslash, L_udmstar, and L_dminus. 

Is it possible that the C compiler is no longer pushing its registers and popping them before and after the calls?

Krishna

--

int C_sharp()
{
  /* stack: ( ud1 -- ud2 | convert one digit of ud1 ) */

  unsigned int u1, u2, rem;
  char ch;

  *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
#ifndef __FAST__
  *GlobalTp-- = *(GlobalTp+2); *GlobalTp-- = *(GlobalTp+2); /*  "  */
#endif
  TOS = 0; /* pad to triple length */
  DEC_DSP
  DEC_DTSP
  TOS = Base;
  DEC_DSP
  DEC_DTSP

  L_utmslash();
  u1 = *(GlobalSp + 1);  /* quotient */
  u2 = *(GlobalSp + 2);

  /* quotient is on the stack; we need the remainder */

  TOS = Base;
  DEC_DSP
  DEC_DTSP
  L_udmstar();
  DROP

  L_dminus();
  rem = *(GlobalSp + 2);  /* get the remainder */

  *(GlobalSp + 1) = u1;   /* replace rem with quotient on the stack */
  *(GlobalSp + 2) = u2;
  ch = (rem < 10) ? (rem + 48) : (rem + 55);
  ++NumberCount;
  NumberBuf[255 - NumberCount] = ch;

  return 0;
}

[toc] | [prev] | [next] | [standalone]

#38222

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-04-16 12:08 +0000
Message-ID	<2015Apr16.140809@mips.complang.tuwien.ac.at>
In reply to	#38221

krishna.myneni@ccreweb.org writes:
>One piece of code which appears to be broken is from the file, vmc.c. It is=
> the implementation of the Forth word "#", shown below. The C function call=
>s exported functions from the assembler file, vm.s. The assembly functions =
>begin with "L_". The three assembler functions used in C_sharp() are L_utms=
>lash, L_udmstar, and L_dminus.=20
>
>Is it possible that the C compiler is no longer pushing its registers and p=
>opping them before and after the calls?

C compilers normally use their calling convention when calling another
function (especially if the function is not known).  Calling
conventions typically have caller-saved registers that the caller
pushes and pops around the call if necessary, and that the callee may
clobber as it likes, and callee-saved registers that have to be
preserved by the called function.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38223

From	krishna.myneni@ccreweb.org
Date	2015-04-16 05:29 -0700
Message-ID	<d79f15c8-5a9d-48e1-984d-d47bec31bd80@googlegroups.com>
In reply to	#38222

On Thursday, April 16, 2015 at 7:13:34 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
...
> >Is it possible that the C compiler is no longer pushing its registers and p=
> >opping them before and after the calls?
> 
> C compilers normally use their calling convention when calling another
> function (especially if the function is not known).  Calling
> conventions typically have caller-saved registers that the caller
> pushes and pops around the call if necessary, and that the callee may
> clobber as it likes, and callee-saved registers that have to be
> preserved by the called function.
> 

How can the C compiler determine which registers need to be pushed and popped, if it didn't compile the function being called? In this case a C function is calling an external assembler function. In the past, I could rely on the C compiler to push all of the usual 32-bit registers (EAX, EBX, ECX, EDX, and maybe a few others) before compiling the call to the external function, and then popping them. Has the calling convention for external functions changed recently in gcc?

Krishna

[toc] | [prev] | [next] | [standalone]

#38225

From	krishna.myneni@ccreweb.org
Date	2015-04-16 07:07 -0700
Message-ID	<3469ca57-8a1b-4337-b1c1-049221763298@googlegroups.com>
In reply to	#38223

Ok. I think I see what you are saying, Anton. The caller does not need to know which registers the callee uses, in order to push necessary regs. The caller needs to know only the regs it uses. Also, I think my statement about relying on specific regs being pushed in the past is inaccurate. kForth does not assume this. It has been awhile since I tinkered with the low level parts. 

So, it appears to me that the caller is not pushing and popping a reg that it uses. But, such a bug in gcc would have catastrophic consequences, and that certainly doesn't seem to be the case. Hmm ...

Krishna

[toc] | [prev] | [next] | [standalone]

#38227

From	franck.bensusan@gmail.com
Date	2015-04-16 07:44 -0700
Message-ID	<1dc7ea06-6f15-4977-bf27-e0832c47ad33@googlegroups.com>
In reply to	#38225

Le jeudi 16 avril 2015 16:07:16 UTC+2, krishna...@ccreweb.org a écrit :
> Ok. I think I see what you are saying, Anton. The caller does not need to know which registers the callee uses, in order to push necessary regs. The caller needs to know only the regs it uses. Also, I think my statement about relying on specific regs being pushed in the past is inaccurate. kForth does not assume this. It has been awhile since I tinkered with the low level parts. 
> 
> So, it appears to me that the caller is not pushing and popping a reg that it uses. But, such a bug in gcc would have catastrophic consequences, and that certainly doesn't seem to be the case. Hmm ...
> 
> Krishna

I don't know if it is the problem, but if you compile using 64bits mode, everything has changed for parameters.

Most parameters are no more pushed on the stack, but sent using registers.

If you use GCC, I think (if I remember) RCX, RDX, R8 and R9 are used to send function parameters.
Callee also except a part of the stack dedicated for him by the caller.

Franck

[toc] | [prev] | [next] | [standalone]

#38229

From	krishna.myneni@ccreweb.org
Date	2015-04-16 08:14 -0700
Message-ID	<f828f7b0-060b-41e0-82dc-ee832ac20bd3@googlegroups.com>
In reply to	#38227

On Thursday, April 16, 2015 at 9:44:57 AM UTC-5, franck....@gmail.com wrote:
> Le jeudi 16 avril 2015 16:07:16 UTC+2, krishna...@ccreweb.org a écrit :
> > Ok. I think I see what you are saying, Anton. The caller does not need to know which registers the callee uses, in order to push necessary regs. The caller needs to know only the regs it uses. Also, I think my statement about relying on specific regs being pushed in the past is inaccurate. kForth does not assume this. It has been awhile since I tinkered with the low level parts. 
> > 
> > So, it appears to me that the caller is not pushing and popping a reg that it uses. But, such a bug in gcc would have catastrophic consequences, and that certainly doesn't seem to be the case. Hmm ...
> > 
> > Krishna
> 
> I don't know if it is the problem, but if you compile using 64bits mode, everything has changed for parameters.
> 
> Most parameters are no more pushed on the stack, but sent using registers.
> 
> If you use GCC, I think (if I remember) RCX, RDX, R8 and R9 are used to send function parameters.
> Callee also except a part of the stack dedicated for him by the caller.
> 
> Franck

Hi Franck,

I can't compile the entire application in 64-bit mode, since kForth uses 32-bit assembly code files (for the gnu assembler). Thanks.

Krishna

[toc] | [prev] | [next] | [standalone]

#38226

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-04-16 14:02 +0000
Message-ID	<2015Apr16.160218@mips.complang.tuwien.ac.at>
In reply to	#38223

krishna.myneni@ccreweb.org writes:
>On Thursday, April 16, 2015 at 7:13:34 AM UTC-5, Anton Ertl wrote:
>> krishna.myneni@ccreweb.org writes:
>...
>> >Is it possible that the C compiler is no longer pushing its registers an=
>d p=3D
>> >opping them before and after the calls?
>>=20
>> C compilers normally use their calling convention when calling another
>> function (especially if the function is not known).  Calling
>> conventions typically have caller-saved registers that the caller
>> pushes and pops around the call if necessary, and that the callee may
>> clobber as it likes, and callee-saved registers that have to be
>> preserved by the called function.
>>=20
>
>How can the C compiler determine which registers need to be pushed and popp=
>ed, if it didn't compile the function being called?

The calling convention tells it what the caller needs to preserve and
what the callee will preserve.  If both parties conform to the
convention, it will work out fine with no need for the caller to know
anything else about the callee and vice versa.

> In this case a C functi=
>on is calling an external assembler function. In the past, I could rely on =
>the C compiler to push all of the usual 32-bit registers (EAX, EBX, ECX, ED=
>X, and maybe a few others) before compiling the call to the external functi=
>on, and then popping them. Has the calling convention for external function=
>s changed recently in gcc?

Doubtful, but maybe the compiler compiles this function differently
now.  Take a look a the assembly code.

So it seems that you are using IA-32, and there are a large number of
calling conventions for that, dependent on OS and compiler.  You can
read about them at
<http://en.wikipedia.org/wiki/X86_calling_conventions>.  E.g., it says:

|cdecl
|
|[...]Registers EAX, ECX, and EDX are caller-saved, and the rest are
|callee-saved.[...]

|Register preservation
|
|[...] According to the Intel ABI to which the vast majority of compilers
|conform, the EAX, EDX, and ECX are to be free for use within a
|procedure or function, and need not be preserved.

The latter means that the callee does not need to preserve them.  EBX
and others are not caller-saved, though, and the callee needs to
preserve them if it uses that register.

If you are relying on gcc, you could also use Extended Assembler
statements instead of functions written in assembly language.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38228

From	krishna.myneni@ccreweb.org
Date	2015-04-16 08:12 -0700
Message-ID	<e4ca4d89-c837-4818-b88b-297d5e624ab4@googlegroups.com>
In reply to	#38226

On Thursday, April 16, 2015 at 9:16:59 AM UTC-5, Anton Ertl wrote:
...
> The calling convention tells it what the caller needs to preserve and
> what the callee will preserve.  If both parties conform to the
> convention, it will work out fine with no need for the caller to know
> anything else about the callee and vice versa.
> 

Thank you. That's clear now.

> > ... In the past, I could rely on 
> >the C compiler to push all of the usual 32-bit registers (EAX, EBX, ECX, ED=
> >X, and maybe a few others) before compiling the call to the external functi=
> >on, and then popping them. Has the calling convention for external function=
> >s changed recently in gcc?
> 
> Doubtful, but maybe the compiler compiles this function differently
> now.  Take a look a the assembly code.
> 
> So it seems that you are using IA-32, and there are a large number of
> calling conventions for that, dependent on OS and compiler.  You can
> read about them at
> <http://en.wikipedia.org/wiki/X86_calling_conventions>.  E.g., it says:
> 
> |cdecl
> |
> |[...]Registers EAX, ECX, and EDX are caller-saved, and the rest are
> |callee-saved.[...]
> 
> 
> |Register preservation
> |
> |[...] According to the Intel ABI to which the vast majority of compilers
> |conform, the EAX, EDX, and ECX are to be free for use within a
> |procedure or function, and need not be preserved.
> 
> The latter means that the callee does not need to preserve them.  EBX
> and others are not caller-saved, though, and the callee needs to
> preserve them if it uses that register.
> 

Yes, I see that EBX is not guaranteed by the Intel convention. However, it appears to not be a problem for the C_sharp() function. The gcc-generated assembler code, below, shows it is not being used here. There may be some other problem. However, I do need to go back and ensure that I'm violating the calling conventions for other exported assembler functions. There are 12 such functions provided by the assembly language portion of kForth.

Thanks for your help, Anton.

Krishna

---

	.globl	C_sharp
	.type	C_sharp, @function
C_sharp:
.LFB46:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	subl	$24, %esp
	movl	GlobalSp, %eax
	leal	-4(%eax), %edx
	movl	%edx, GlobalSp
	movl	GlobalSp, %edx
	movl	8(%edx), %edx
	movl	%edx, (%eax)
	movl	GlobalSp, %eax
	leal	-4(%eax), %edx
	movl	%edx, GlobalSp
	movl	GlobalSp, %edx
	movl	8(%edx), %edx
	movl	%edx, (%eax)
	movl	GlobalTp, %eax
	leal	-1(%eax), %edx
	movl	%edx, GlobalTp
	movl	GlobalTp, %edx
	movzbl	2(%edx), %edx
	movb	%dl, (%eax)
	movl	GlobalTp, %eax
	leal	-1(%eax), %edx
	movl	%edx, GlobalTp
	movl	GlobalTp, %edx
	movzbl	2(%edx), %edx
	movb	%dl, (%eax)
	movl	GlobalSp, %eax
	movl	$0, (%eax)
	movl	GlobalSp, %eax
	subl	$4, %eax
	movl	%eax, GlobalSp
	movl	GlobalTp, %eax
	subl	$1, %eax
	movl	%eax, GlobalTp
	movl	GlobalSp, %eax
	movl	Base, %edx
	movl	%edx, (%eax)
	movl	GlobalSp, %eax
	subl	$4, %eax
	movl	%eax, GlobalSp
	movl	GlobalTp, %eax
	subl	$1, %eax
	movl	%eax, GlobalTp
	call	L_utmslash
	movl	GlobalSp, %eax
	addl	$4, %eax
	movl	(%eax), %eax
	movl	%eax, -12(%ebp)
	movl	GlobalSp, %eax
	addl	$8, %eax
	movl	(%eax), %eax
	movl	%eax, -16(%ebp)
	movl	GlobalSp, %eax
	movl	Base, %edx
	movl	%edx, (%eax)
	movl	GlobalSp, %eax
	subl	$4, %eax
	movl	%eax, GlobalSp
	movl	GlobalTp, %eax
	subl	$1, %eax
	movl	%eax, GlobalTp
	call	L_udmstar
	movl	GlobalSp, %eax
	addl	$4, %eax
	movl	%eax, GlobalSp
	movl	GlobalTp, %eax
	addl	$1, %eax
	movl	%eax, GlobalTp
	call	L_dminus
	movl	GlobalSp, %eax
	addl	$8, %eax
	movl	(%eax), %eax
	movl	%eax, -20(%ebp)
	movl	GlobalSp, %eax
	leal	4(%eax), %edx
	movl	-12(%ebp), %eax
	movl	%eax, (%edx)
	movl	GlobalSp, %eax
	leal	8(%eax), %edx
	movl	-16(%ebp), %eax
	movl	%eax, (%edx)
	cmpl	$9, -20(%ebp)
	ja	.L180
	movl	-20(%ebp), %eax
	addl	$48, %eax
	jmp	.L181
.L180:
	movl	-20(%ebp), %eax
	addl	$55, %eax
.L181:
	movb	%al, -21(%ebp)
	movl	NumberCount, %eax
	addl	$1, %eax
	movl	%eax, NumberCount
	movl	NumberCount, %eax
	movl	$255, %edx
	subl	%eax, %edx
	movzbl	-21(%ebp), %eax
	movb	%al, NumberBuf(%edx)
	movl	$0, %eax
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE46:
	.size	C_sharp, .-C_sharp

[toc] | [prev] | [next] | [standalone]

#38235

From	krishna.myneni@ccreweb.org
Date	2015-04-16 12:25 -0700
Message-ID	<de194ec8-75d4-4f9d-ba5e-7c206a57416a@googlegroups.com>
In reply to	#38221

On Thursday, April 16, 2015 at 6:55:12 AM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 6:13:26 AM UTC-5, krishna...@ccreweb.org wrote:
...
> 
> One piece of code which appears to be broken is from the file, vmc.c. It is the implementation of the Forth word "#", shown below. ...
> 
> --
> 
> int C_sharp()
> {
>   /* stack: ( ud1 -- ud2 | convert one digit of ud1 ) */
> 
>   unsigned int u1, u2, rem;
>   char ch;
> 
>   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> ...

On a whim, I thought I would test the compiler with code similar to the last line above. I'm finding this hard to believe, but gcc 4.8.3 appears to mis-compile the following code with the -m32 flag:

=====
/*
Check gcc 4.8.3, 32-bit compilation of following code.

Compile with "gcc -o miscomp -m32 miscomp.c"
*/

#include <stdio.h>
int main()
{
	unsigned int  stk[10];
	unsigned int* sp = &stk[8];

	stk[9] = 34;
	*sp-- = *(sp + 1);
        printf( "%d %d\n", stk[9], stk[8] );

	return(0);
}
=====

Here is the output from executing the above:

$ ./miscomp
34 47


Under gcc 4.4.7, the execution output is,

$ ./miscomp
34 34


What am I missing?

Krishna

[toc] | [prev] | [next] | [standalone]

#38240

From	krishna.myneni@ccreweb.org
Date	2015-04-16 17:02 -0700
Message-ID	<29c7eb53-229e-40a4-9bad-0d14e953ebc3@googlegroups.com>
In reply to	#38235

On Thursday, April 16, 2015 at 2:25:20 PM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 6:55:12 AM UTC-5, krishna...@ccreweb.org wrote:
> > On Thursday, April 16, 2015 at 6:13:26 AM UTC-5, krishna...@ccreweb.org wrote:
> ...
> > 
> > One piece of code which appears to be broken is from the file, vmc.c. It is the implementation of the Forth word "#", shown below. ...
> > 
> > --
> > 
> > int C_sharp()
> > {
> >   /* stack: ( ud1 -- ud2 | convert one digit of ud1 ) */
> > 
> >   unsigned int u1, u2, rem;
> >   char ch;
> > 
> >   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> > ...
> 
> On a whim, I thought I would test the compiler with code similar to the last line above. ...


I can confirm that the example problem,

1024 s>d <# #s #> type

works correctly when I recode the above line as follows,

//  *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
  *GlobalSp = *(GlobalSp+2);
  --GlobalSp;
  *GlobalSp = *(GlobalSp+2);
  --GlobalSp;
#ifndef __FAST__
//  *GlobalTp-- = *(GlobalTp+2); *GlobalTp-- = *(GlobalTp+2); /*  "  */
  *GlobalTp = *(GlobalTp+2);
  --GlobalTp;
  *GlobalTp = *(GlobalTp+2);
  --GlobalTp;
#endif


Wow. What is the prpblem with gcc 4.8 and higher (I see the same problem with gcc 4.9 on the fedora 21 system)?

Krishna

[toc] | [prev] | [next] | [standalone]

#38241

From	krishna.myneni@ccreweb.org
Date	2015-04-16 17:06 -0700
Message-ID	<afa7fe19-fb96-49d4-be33-6f2677fcd1da@googlegroups.com>
In reply to	#38240

On Thursday, April 16, 2015 at 7:02:28 PM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 2:25:20 PM UTC-5, krishna...@ccreweb.org wrote:
> > On Thursday, April 16, 2015 at 6:55:12 AM UTC-5, krishna...@ccreweb.org wrote:
> > > On Thursday, April 16, 2015 at 6:13:26 AM UTC-5, krishna...@ccreweb.org wrote:
> > ...
> > > 
> > > One piece of code which appears to be broken is from the file, vmc.c. It is the implementation of the Forth word "#", shown below. ...
> > > 
> > > --
> > > 
> > > int C_sharp()
> > > {
> > >   /* stack: ( ud1 -- ud2 | convert one digit of ud1 ) */
> > > 
> > >   unsigned int u1, u2, rem;
> > >   char ch;
> > > 
> > >   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> > > ...
> > 
> > On a whim, I thought I would test the compiler with code similar to the last line above. ...
> 
> 
> I can confirm that the example problem,
> 
> 1024 s>d <# #s #> type
> 
> works correctly when I recode the above line as follows,
> ... 


I also confirm that the Hayes core tests for kForth pass as well, with the code change mentioned in the previous message.

KM

[toc] | [prev] | [next] | [standalone]

#38242

From	foxaudioresearch@gmail.com
Date	2015-04-16 17:24 -0700
Message-ID	<87f18d43-a91e-4ae7-b98a-2cf4b7227c47@googlegroups.com>
In reply to	#38241

On Thursday, April 16, 2015 at 8:06:24 PM UTC-4, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 7:02:28 PM UTC-5, krishna...@ccreweb.org wrote:
> > On Thursday, April 16, 2015 at 2:25:20 PM UTC-5, krishna...@ccreweb.org wrote:
> > > On Thursday, April 16, 2015 at 6:55:12 AM UTC-5, krishna...@ccreweb.org wrote:
> > > > On Thursday, April 16, 2015 at 6:13:26 AM UTC-5, krishna...@ccreweb.org wrote:
> > > ...
> > > > 
> > > > One piece of code which appears to be broken is from the file, vmc.c. It is the implementation of the Forth word "#", shown below. ...
> > > > 
> > > > --
> > > > 
> > > > int C_sharp()
> > > > {
> > > >   /* stack: ( ud1 -- ud2 | convert one digit of ud1 ) */
> > > > 
> > > >   unsigned int u1, u2, rem;
> > > >   char ch;
> > > > 
> > > >   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> > > > ...
> > > 
> > > On a whim, I thought I would test the compiler with code similar to the last line above. ...
> > 
> > 
> > I can confirm that the example problem,
> > 
> > 1024 s>d <# #s #> type
> > 
> > works correctly when I recode the above line as follows,
> > ... 
> 
> 
> I also confirm that the Hayes core tests for kForth pass as well, with the code change mentioned in the previous message.
> 
> KM


As one who does not spin in the GCC circles, how does one report such a situation and is there an expectation of when it will be fixed?

It makes me appreciate being able to reach inside and look under the hood of a Forth compiler and actually understand it.

BF

[toc] | [prev] | [next] | [standalone]

#38243

From	krishna.myneni@ccreweb.org
Date	2015-04-16 17:39 -0700
Message-ID	<0bf84b5a-58fe-4e40-a1c8-7e27b18b0029@googlegroups.com>
In reply to	#38242

The place to report gcc bugs appears to be at this link:

https://gcc.gnu.org/bugzilla/

It would seem to me that this particular bug, which is also manifested with 64 bit compilation, could break a lot of existing code, as the particular coding style is not unusual. The compiler fails silently, so only runtime behavior is likely to reveal it to users.

I will submit a bug report. Possibly it has been reported earlier.

Krishna

[toc] | [prev] | [next] | [standalone]

#38244

From	Paul Rubin <no.email@nospam.invalid>
Date	2015-04-16 17:47 -0700
Message-ID	<87y4lrwpfo.fsf@jester.gateway.pace.com>
In reply to	#38242

foxaudioresearch@gmail.com writes:
>> > > >   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> As one who does not spin in the GCC circles, how does one report such
> a situation and is there an expectation of when it will be fixed?

I think the old code was not valid C since there is no sequence point
created by the assignment operator.  See:

  http://c-faq.com/expr/seqpoints.html

It may have happened to work for a while but it was not guaranteed by
the C spec.

> It makes me appreciate being able to reach inside and look under the
> hood of a Forth compiler and actually understand it.

It's not a matter of examining the compiler.  The C language
specification is full of hazards like that, possibly to allow added
parallelization opportunities for the compiler.

[toc] | [prev] | [next] | [standalone]

#38245

From	krishna.myneni@ccreweb.org
Date	2015-04-16 18:44 -0700
Message-ID	<ee3a191f-4d42-45d1-9c8d-9883b46dcc24@googlegroups.com>
In reply to	#38244

On Thursday, April 16, 2015 at 7:47:57 PM UTC-5, Paul Rubin wrote:
> foxaudioresearch@gmail.com writes:
> >> > > >   *GlobalSp-- = *(GlobalSp+2); *GlobalSp-- = *(GlobalSp+2); /* 2dup */
> > As one who does not spin in the GCC circles, how does one report such
> > a situation and is there an expectation of when it will be fixed?
> 
> I think the old code was not valid C since there is no sequence point
> created by the assignment operator.  See:
> 
>   http://c-faq.com/expr/seqpoints.html
> 

I don't see the correspondence. The same quantity is not being modified twice within the expression. Neither the pointer, GlobalSp, or its contents are altered twice within the expression. The expression appears valid to me.

Krishna

[toc] | [prev] | [next] | [standalone]

#38246

From	krishna.myneni@ccreweb.org
Date	2015-04-16 18:50 -0700
Message-ID	<e0adb3c5-88e7-4600-a5fb-e2e72dcd5356@googlegroups.com>
In reply to	#38245

On Thursday, April 16, 2015 at 8:44:47 PM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 7:47:57 PM UTC-5, Paul Rubin wrote:

> > I think the old code was not valid C since there is no sequence point
> > created by the assignment operator.  See:
> > 
> >   http://c-faq.com/expr/seqpoints.html
> > 
> 
> I don't see the correspondence. The same quantity is not being modified twice within the expression. Neither the pointer, GlobalSp, or its contents are altered twice within the expression. The expression appears valid to me.
> 

More specifically, the faq says,

"This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification."

That is true for an expression such as,

   *sp-- = *(sp + 1)

This lays out a pretty specific sequence for access and assignment. Are you saying that the LHS can be (partially) evaluated before the RHS? 

KM

[toc] | [prev] | [next] | [standalone]

#38247

From	Paul Rubin <no.email@nospam.invalid>
Date	2015-04-16 19:10 -0700
Message-ID	<87twwfwlm2.fsf@jester.gateway.pace.com>
In reply to	#38246

krishna.myneni@ccreweb.org writes:
>    *sp-- = *(sp + 1)
> This lays out a pretty specific sequence for access and
> assignment. Are you saying that the LHS can be (partially) evaluated
> before the RHS?

Yes, I believe so.  The condition that says thing A must be evaluated
before thing B is the presence of a sequence point between A and B.  And
it's explicit that an assignment operator (the = sign) does not create a
sequence point.  See the paragraph in that FAQ starting

    The second sentence can be quite difficult to understand. It turns out
    that it disallows code like
            a[i] = i++
    ...

for more discussion.  This is similar, I think.

[toc] | [prev] | [next] | [standalone]

Page 1 of 6 [1] 2 3 4 5 6 Next page →

csiph-web

rhel 7 and kforth

Contents

#38202 — rhel 7 and kforth

#38210

#38220

#38221

#38222

#38223

#38225

#38227

#38229

#38226

#38228

#38235

#38240

#38241

#38242

#38243

#38244

#38245

#38246

#38247