Re: pforth v27 compilation problems.
Phil Burk
Thanks for reporting these problems.
> v27 compiles and works fine on Linux, but won't compile for Windows
> 32-bit.
How were you compiling it? What was the error message?
> I fixed the basic compilation problems relating to stdint.h under
> win32 for v27, and you can have that if you want,
Yes, please.
> found serious compiler warnings.
I will try to build under VS2010 to see what sort of warnings I get.
If we can't find the specific issues then I may ask you to file an Issue
on the pForth code site:
http://code.google.com/p/pforth/issues/list
Thanks,
Phil Burk
On 2/16/12 5:50 AM, bifferos wrote:
> Hi Phil,
>
> v27 compiles and works fine on Linux, but won't compile for Windows
> 32-bit. v24 compiles for Windows 32-bit, but won't do a lot when I
> run it as it complains about not being able to load a dictionary. v24
> also comes up with errors when I try to compile it under Linux, so
> it's not really possible for me to work with either in their current
> form, as I'd like my code to work on both platforms.
>
> It does seem as though it's only you +Aleksej who actually used v27
> so far, judging by feedback on the group. I am happy to try to fix
> the issues with this but will need some hand-holding as I'm very new
> to forth. I have a machine with vs2003, vs2005, vs2008 on it so I can
> test those configurations, I can probably also get vs2010 if needed.
>
> I fixed the basic compilation problems relating to stdint.h under
> win32 for v27, and you can have that if you want, but then I also
> found serious compiler warnings. There are 64-bit shift operations
> being performed on 32-bit data, perhaps because the wrong thing is
> happening when _WIN64 not defined (32-bit compiler), and that's
> probably not a good!
>
> If you need more details or any help with this please let me know.
>
> regards, Biff.
>
>
>
>
>
>
>
>
>
>
>
bifferos
> Hello Biff,
>
> Thanks for reporting these problems.
>
> > v27 compiles and works fine on Linux, but won't compile for Windows
> > 32-bit.
>
> How were you compiling it? What was the error message?
about missing stdint.h
> > I fixed the basic compilation problems relating to stdint.h under
> > win32 for v27, and you can have that if you want,
>
> Yes, please.
Monday, but I put something like this in pforth.h:
#ifdef WIN32
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
typedef char int8_t;
typedef short int16_t;
typedef long int32_t;
#else
#include <stdint.h>
#endif
I don't really know if that's the best way to fix it, perhaps the
win32 port should just provide it's own stdint.h in a win32 specific
directory and add that to the include path.
>
> > found serious compiler warnings.
>
> I will try to build under VS2010 to see what sort of warnings I get.
>
> If we can't find the specific issues then I may ask you to file an Issue
> on the pForth code site:
>
> http://code.google.com/p/pforth/issues/list
http://code.google.com/p/pforth/source/browse/trunk/csrc/pf_save.c
void WriteCellBigEndian( uint8_t *addr, ucell_t data )
{
/* Write should be in order of increasing address
* to optimize for burst writes to DRAM. */
if( sizeof(ucell_t) == 8 )
{
*addr++ = (uint8_t) (data>>56);
*addr++ = (uint8_t) (data>>48);
*addr++ = (uint8_t) (data>>40);
*addr++ = (uint8_t) (data>>32);
}
It appears that ucell_t is only 32-bit and so the compiler complains
about the shift operations producing undefined behaviour.
>
> Thanks,
> Phil Burk
cheers,
Biff.
Aleksej Saushev
bifferos <biff...@yahoo.co.uk> writes:
> On Feb 16, 6:52 pm, Phil Burk <philb...@mobileer.com> wrote:
>> Hello Biff,
>>
>> Thanks for reporting these problems.
>>
>> > v27 compiles and works fine on Linux, but won't compile for Windows
>> > 32-bit.
>>
>> How were you compiling it? What was the error message?
>
> Just opened the .sln file and built from there. There were errors
> about missing stdint.h
<stdint.h> is mandatory part of the language.
>> > I fixed the basic compilation problems relating to stdint.h under
>> > win32 for v27, and you can have that if you want,
>>
>> Yes, please.
>
> Unfortunately I won't have access to the machine I did this on until
> Monday, but I put something like this in pforth.h:
>
> #ifdef WIN32
> typedef unsigned char uint8_t;
> typedef unsigned short uint16_t;
> typedef unsigned long uint32_t;
> typedef char int8_t;
> typedef short int16_t;
> typedef long int32_t;
> #else
> #include <stdint.h>
> #endif
>
> I don't really know if that's the best way to fix it, perhaps the
> win32 port should just provide it's own stdint.h in a win32 specific
> directory and add that to the include path.
Fix your compiler.
Seriously, <stdint.h> is mandatory part of the language, and "if an
implementation provides integer types with widths of 8, 16, 32, or 64
bits, no padding bits, and (for the signed types) that have a two's
complement representation, it shall define the corresponding typedef
names." It follows that your compiler doesn't implement C language as
defined by ISO/IEC 9899. In fact, not having <stdint.h> is asking for
problems these days, you have to implement one sooner or later if doing
any serious work.
>> > found serious compiler warnings.
>>
>> I will try to build under VS2010 to see what sort of warnings I get.
>>
>> If we can't find the specific issues then I may ask you to file an Issue
>> on the pForth code site:
>>
>> http://code.google.com/p/pforth/issues/list
>
> No problem. The warning was here:
> http://code.google.com/p/pforth/source/browse/trunk/csrc/pf_save.c
>
> void WriteCellBigEndian( uint8_t *addr, ucell_t data )
> {
> /* Write should be in order of increasing address
> * to optimize for burst writes to DRAM. */
> if( sizeof(ucell_t) == 8 )
> {
> *addr++ = (uint8_t) (data>>56);
> *addr++ = (uint8_t) (data>>48);
> *addr++ = (uint8_t) (data>>40);
> *addr++ = (uint8_t) (data>>32);
> }
>
> It appears that ucell_t is only 32-bit and so the compiler complains
> about the shift operations producing undefined behaviour.
This is actually impossible to fix without solutions like autoconf or
BSD config(8). C isn't nice language for this sort of things.
--
HE CE3OH...
Phil Burk
On 2/16/12 1:16 PM, Aleksej Saushev wrote:
> bifferos<biff...@yahoo.co.uk> writes:
>> I don't really know if that's the best way to fix it, perhaps the
>> win32 port should just provide it's own stdint.h in a win32 specific
>> directory and add that to the include path.
>
> Fix your compiler.
> Seriously,<stdint.h> is mandatory part of the language,
Just because something is "mandatory" does not mean that Microsoft is
going to do it. And given that Microsoft is running on a fair number of
platforms, pForth should not rely on the presence of <stdint.h>.
The 'p' in pForth stands for portable. We want pForth to compile on as
many platforms as possible, regardless of whether that platform complies
with the "mandatory" 'C' requirements. In some cases the platform may
have no OS and an experimental in-house 'C' compiler.
I see an Issue has already been filed for this on GNU platform so the
problem is not limited to Microsoft:
<http://code.google.com/p/pforth/issues/detail?id=14>
I think Biff's approach is reasonable. When the standard types are not
available in a header then we should define them.
I will test pForth on more Windows platforms and make sure pForth is
still portable.
BTW, here is an interesting discussion on stdint.h and MS Visual Studio.
<http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio>
Thanks,
Phil Burk
bifferos
> Hello,
>
> On 2/16/12 1:16 PM, Aleksej Saushev wrote:
>
> >> win32 port should just provide it's own stdint.h in a win32 specific
> >> directory and add that to the include path.
>
> > Fix your compiler.
> > Seriously,<stdint.h> is mandatory part of the language,
>
> Just because something is "mandatory" does not mean that Microsoft is
> going to do it. And given that Microsoft is running on a fair number of
> platforms, pForth should not rely on the presence of <stdint.h>.
vs2003 -> vs2008 were C99, so it's not really surprising when you find
that they're not. The homepage for pforth states that it's Ansi C,
which I presume means C89, so it should compile with these compilers.
stdint.h is only mandatory for C99.
> I think Biff's approach is reasonable. When the standard types are not
> available in a header then we should define them.
#ifdef WIN32
#include "vc_stdint.h"
#else
#include <stdint.h>
#endif
Instead of what I suggested earlier. You can even switch out that
'legacy' stdint.h for later visual studio versions which have it, e.g.
vs2010. There is a #define that specifies the compiler version.
Did you confirm if this compiles/runs with vs2010?
regards,
Biff.
Aleksej Saushev
bifferos <biff...@yahoo.co.uk> writes:
> On Feb 16, 9:57 pm, Phil Burk <philb...@mobileer.com> wrote:
>> Hello,
>>
>> On 2/16/12 1:16 PM, Aleksej Saushev wrote:
>>
>> > bifferos<biffe...@yahoo.co.uk> writes:
>> >> I don't really know if that's the best way to fix it, perhaps the
>> >> win32 port should just provide it's own stdint.h in a win32 specific
>> >> directory and add that to the include path.
>>
>> > Fix your compiler.
>> > Seriously,<stdint.h> is mandatory part of the language,
>>
>> Just because something is "mandatory" does not mean that Microsoft is
>> going to do it. And given that Microsoft is running on a fair number of
>> platforms, pForth should not rely on the presence of <stdint.h>.
>
> Actually, you can't blame Microsoft for this one. They never claimed
> vs2003 -> vs2008 were C99, so it's not really surprising when you find
> that they're not. The homepage for pforth states that it's Ansi C,
> which I presume means C89, so it should compile with these compilers.
> stdint.h is only mandatory for C99.
ANSI C is the same standard since ANSI approval of ISO/IEC 9899 in May 2000.
>> I think Biff's approach is reasonable. When the standard types are not
>> available in a header then we should define them.
>
> It would be perhaps more elegant to do something like:
>
> #ifdef WIN32
> #include "vc_stdint.h"
> #else
> #include <stdint.h>
> #endif
>
> Instead of what I suggested earlier. You can even switch out that
> 'legacy' stdint.h for later visual studio versions which have it, e.g.
> vs2010. There is a #define that specifies the compiler version.
>
> Did you confirm if this compiles/runs with vs2010?
In this case the better solution is to import some public domain stdint.h
or adopt one from any BSD. "<>" means that the file is searched in system
headers first then in path as defined by flags.
--
HE CE3OH...
bifferos
On Feb 16, 10:35 pm, Aleksej Saushev <a...@inbox.ru> wrote:
> > Actually, you can't blame Microsoft for this one. They never claimed
> > vs2003 -> vs2008 were C99, so it's not really surprising when you find
> > that they're not. The homepage for pforth states that it's Ansi C,
> > which I presume means C89, so it should compile with these compilers.
> > stdint.h is only mandatory for C99.
>
> ANSI C is the same standard since ANSI approval of ISO/IEC 9899 in May 2000.
understand to be 'Ansi C'. Most people spell it out, e.g. C99, and
this ensures that people don't get confused.
A quick google finds this page:
http://en.wikipedia.org/wiki/ANSI_C
Which says:
C89 .... This version of the language is often referred to as "ANSI
C"....
C99 .... This standard is commonly referred to as C99....
Perhaps it's a little like when I 'hoover' my floor. I'm not actually
using a Hoover, but most people know what I mean.
> > #ifdef WIN32
> > #include "vc_stdint.h"
> > #else
> > #include <stdint.h>
> > #endif
create a trivial file with only the definitions that are required.
> or adopt one from any BSD.
from BSD are not BSD-licensed (always possible, I think there is some
public domain stuff in BSD).
> "<>" means that the file is searched in system headers first then in path as defined by flags.
project, and it should/must not be called stdint.h if it isn't a
complete implementation.
But hey, I don't really want to get hung up about how things are done
around here, I am just the new guy who wants it to compile and run,
preferably on vs2005, but if I'm really pushed I suppose I can use
vs2010.
Biff.
Phil Burk
PForth used to be portable and did not rely on <stdint.h>. I think we
can make it portable once again. Adding our own typedefs will be a
start. Something like:
#ifdef HAS_STDINT
#include <stdint.h>
#else
typedef unsigned char uint8_t;
...etcetera...
#endif
> But hey, I don't really want to get hung up about how things are done
> around here, I am just the new guy who wants it to compile and run,
Your input is much appreciated. We also want it to compile and run.
Thanks for pointing out the problem with MSVC200x.
Phil Burk
bifferos
As I said before I would like to help, but I'm not sure I understand
what the 64-bit stuff is supposed to be about. Is the aim to use 64-
bit instructions where available, or is it about running on 64-bit
operating systems or is it just about supporting 64-bit word sizes (on
64 or 32-bit systems)?
If the latest changes broke all windows targets then it's probably
better if I let someone else fix this, on the other hand, if there is
just one microsoft windows target where it's broken I am probably up
to fixing it for the other ones. I certainly don't want to fix the 32-
bit compile only to break 64-bit support somehow.
regards,
Biff.
bifferos
On Feb 18, 1:03 pm, bifferos <biffe...@yahoo.co.uk> wrote:
> just one microsoft windows target where it's broken I am probably up
*working*"
Aleksej Saushev
> As I said before I would like to help, but I'm not sure I understand
> what the 64-bit stuff is supposed to be about. Is the aim to use 64-
> bit instructions where available, or is it about running on 64-bit
> operating systems or is it just about supporting 64-bit word sizes (on
> 64 or 32-bit systems)?
Both.
(Note that there're few bugs that went unnoticed and were fixed after I forked.)
--
HE CE3OH...