'-DNDEBUG=0' and '-DDEBUGVM=1'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

'-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 
Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong.

First, what are those flags intended for?   Which should be tuned on and which one off for both, release and debug ?

In Unix/Windows conf, onlt for release, these are set:
-DDEBUGVM=0 -DNDEBUG

Mac Carbon release
-DDEBUGVM=0 -DNDEBUG=1

Mac Cocoa Cog (CocoaIOSCogConfig) debug
 '-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog (CocoaIOSCogConfig) release
'-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog MT  debug
-DNDEBUG=0' '-DDEBUGVM=1'

Mac Cocoa Cog MT  release
'-DNDEBUG=0' '-DDEBUGVM=1'


So...this is a mess.  Mac Cocoa Cog MT,  have the same for both release and debug. Is this correct?
Mac Cocoa Cog, idem Mac Cocoa Cog MT

What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog

so...i have no idea how this should be, but sounds strange for me

Cheers

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Eliot Miranda-2
 


On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote:
 
Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong.

First, what are those flags intended for?   Which should be tuned on and which one off for both, release and debug ?

NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts.  To get asserts working in Cog it was easiest to use this flag.  So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning).  See platforms/Cross/vm/sqAssert.h.  Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.

DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code.  Seer DEBUGVM and Debug in src/vm/cogit.c.  I needed this early on in development when the system was flakey.  Now I never use it.  One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64).  So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug.

HTH
Eliot


In Unix/Windows conf, onlt for release, these are set:
-DDEBUGVM=0 -DNDEBUG

Mac Carbon release
-DDEBUGVM=0 -DNDEBUG=1

Mac Cocoa Cog (CocoaIOSCogConfig) debug
 '-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog (CocoaIOSCogConfig) release
'-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog MT  debug
-DNDEBUG=0' '-DDEBUGVM=1'

Mac Cocoa Cog MT  release
'-DNDEBUG=0' '-DDEBUGVM=1'


So...this is a mess.  Mac Cocoa Cog MT,  have the same for both release and debug. Is this correct?
Mac Cocoa Cog, idem Mac Cocoa Cog MT

What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog

so...i have no idea how this should be, but sounds strange for me

Cheers

--
Mariano
http://marianopeck.wordpress.com



Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 
Thanks Eliot for the explanation. So, some of those confs are incorrect. I will commit a fix tonight.

Mariano

On Wed, Apr 13, 2011 at 6:35 PM, Eliot Miranda <[hidden email]> wrote:
 


On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote:
 
Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong.

First, what are those flags intended for?   Which should be tuned on and which one off for both, release and debug ?

NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts.  To get asserts working in Cog it was easiest to use this flag.  So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning).  See platforms/Cross/vm/sqAssert.h.  Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.

DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code.  Seer DEBUGVM and Debug in src/vm/cogit.c.  I needed this early on in development when the system was flakey.  Now I never use it.  One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64).  So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug.

HTH
Eliot


In Unix/Windows conf, onlt for release, these are set:
-DDEBUGVM=0 -DNDEBUG

Mac Carbon release
-DDEBUGVM=0 -DNDEBUG=1

Mac Cocoa Cog (CocoaIOSCogConfig) debug
 '-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog (CocoaIOSCogConfig) release
'-DNDEBUG=1' '-DDEBUGVM=0'

Mac Cocoa Cog MT  debug
-DNDEBUG=0' '-DDEBUGVM=1'

Mac Cocoa Cog MT  release
'-DNDEBUG=0' '-DDEBUGVM=1'


So...this is a mess.  Mac Cocoa Cog MT,  have the same for both release and debug. Is this correct?
Mac Cocoa Cog, idem Mac Cocoa Cog MT

What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog

so...i have no idea how this should be, but sounds strange for me

Cheers

--
Mariano
http://marianopeck.wordpress.com







--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko

On 13 April 2011 18:52, Mariano Martinez Peck <[hidden email]> wrote:
>
> Thanks Eliot for the explanation. So, some of those confs are incorrect. I will commit a fix tonight.
>

And with comments, comments! :)
Thank you both!

> Mariano
>
> On Wed, Apr 13, 2011 at 6:35 PM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong.
>>>
>>> First, what are those flags intended for?   Which should be tuned on and which one off for both, release and debug ?
>>
>> NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts.  To get asserts working in Cog it was easiest to use this flag.  So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning).  See platforms/Cross/vm/sqAssert.h.  Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.
>> DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code.  Seer DEBUGVM and Debug in src/vm/cogit.c.  I needed this early on in development when the system was flakey.  Now I never use it.  One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64).  So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug.
>> HTH
>> Eliot
>>>
>>> In Unix/Windows conf, onlt for release, these are set:
>>> -DDEBUGVM=0 -DNDEBUG
>>>
>>> Mac Carbon release
>>> -DDEBUGVM=0 -DNDEBUG=1
>>>
>>> Mac Cocoa Cog (CocoaIOSCogConfig) debug
>>>  '-DNDEBUG=1' '-DDEBUGVM=0'
>>>
>>> Mac Cocoa Cog (CocoaIOSCogConfig) release
>>> '-DNDEBUG=1' '-DDEBUGVM=0'
>>>
>>> Mac Cocoa Cog MT  debug
>>> -DNDEBUG=0' '-DDEBUGVM=1'
>>>
>>> Mac Cocoa Cog MT  release
>>> '-DNDEBUG=0' '-DDEBUGVM=1'
>>>
>>>
>>> So...this is a mess.  Mac Cocoa Cog MT,  have the same for both release and debug. Is this correct?
>>> Mac Cocoa Cog, idem Mac Cocoa Cog MT
>>>
>>> What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog
>>>
>>> so...i have no idea how this should be, but sounds strange for me
>>>
>>> Cheers
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 
I've just commited the fix, but not the comment ;)

Seriously, I don't know how we can document this kind of things.
Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease   doesn't make sense because they are aprox. 12 implementaions...I don't want to copy paste to all of them. Only in one? it doesn't make sense because people won't see it. So..how we document this kind of things?  I have no idea.

The same with class comments. There are so many classes that copy pasting or documenting only one doesn't make sense.

The only thing I though is doing something like this:


compilerFlagsRelease
    ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks' '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer' '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse' '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST' '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP' '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0' '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')

>>debugVMFlagEnable: boolean
"THIS flag is blagh...blh..."
^ '-DDEBUGVM=', boolean asNumber asString

or something like that...


cheers

Mariano


On Wed, Apr 13, 2011 at 6:57 PM, Igor Stasenko <[hidden email]> wrote:

On 13 April 2011 18:52, Mariano Martinez Peck <[hidden email]> wrote:
>
> Thanks Eliot for the explanation. So, some of those confs are incorrect. I will commit a fix tonight.
>

And with comments, comments! :)
Thank you both!

> Mariano
>
> On Wed, Apr 13, 2011 at 6:35 PM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Apr 13, 2011 at 9:06 AM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> Hi Eliot. I am not sure if I understand correctly these flags, and if I do, then I think the CMake configurations are wrong.
>>>
>>> First, what are those flags intended for?   Which should be tuned on and which one off for both, release and debug ?
>>
>> NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts.  To get asserts working in Cog it was easiest to use this flag.  So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning).  See platforms/Cross/vm/sqAssert.h.  Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.
>> DEBUGVM is a flag controlling details of code generation for the entry-points that jump from the interpreter into machine code.  Seer DEBUGVM and Debug in src/vm/cogit.c.  I needed this early on in development when the system was flakey.  Now I never use it.  One might suggest eliminating it but it will probably be useful again when we add new code generators (e.g. for ARM and x86-64).  So DEBUGVM=0 for production and assert VMs and either 1 or 0 for debug VMs, depending on what kind of problems you're looking to debug.
>> HTH
>> Eliot
>>>
>>> In Unix/Windows conf, onlt for release, these are set:
>>> -DDEBUGVM=0 -DNDEBUG
>>>
>>> Mac Carbon release
>>> -DDEBUGVM=0 -DNDEBUG=1
>>>
>>> Mac Cocoa Cog (CocoaIOSCogConfig) debug
>>>  '-DNDEBUG=1' '-DDEBUGVM=0'
>>>
>>> Mac Cocoa Cog (CocoaIOSCogConfig) release
>>> '-DNDEBUG=1' '-DDEBUGVM=0'
>>>
>>> Mac Cocoa Cog MT  debug
>>> -DNDEBUG=0' '-DDEBUGVM=1'
>>>
>>> Mac Cocoa Cog MT  release
>>> '-DNDEBUG=0' '-DDEBUGVM=1'
>>>
>>>
>>> So...this is a mess.  Mac Cocoa Cog MT,  have the same for both release and debug. Is this correct?
>>> Mac Cocoa Cog, idem Mac Cocoa Cog MT
>>>
>>> What is worst, Mac Cocoa Cog MT is the opposite of Mac Cocoa Cog
>>>
>>> so...i have no idea how this should be, but sounds strange for me
>>>
>>> Cheers
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>



--
Best regards,
Igor Stasenko AKA sig.



--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

'-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko

On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:

> I've just commited the fix, but not the comment ;)
>
> Seriously, I don't know how we can document this kind of things.
> Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
> doesn't make sense because they are aprox. 12 implementaions...I don't want
> to copy paste to all of them. Only in one? it doesn't make sense because
> people won't see it. So..how we document this kind of things?  I have no
> idea.
>
> The same with class comments. There are so many classes that copy pasting or
> documenting only one doesn't make sense.
>

The root class is enough.
A subclasses should just say something like 'i am special for
___that__ and do things differently because i want __that__'.


> The only thing I though is doing something like this:
>
>
> compilerFlagsRelease
>     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
> '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
> '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
> '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
> '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
> '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
> '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
> '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>
>>>debugVMFlagEnable: boolean
> "THIS flag is blagh...blh..."
> ^ '-DDEBUGVM=', boolean asNumber asString
>
> or something like that...
>
>

This knowledge is important. It of course a question where to put that,
but that's exactly why i didn't wanted to use autoconf to generate
config.h file, which contains like 50 various flags,
without any clues, where these flags being used, and in what
situations they should be turned on or off..

So, later we could step over every flag and properly document them,
and like that, for people who will come later, we will have an idea
what are need to deal with and why.

> cheers
>
> Mariano
>

--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 
Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:

add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)

I modified the StackInterpreter to this:

lookupMethodInClass: class
    | currentClass dictionary found |
    <inline: false>
    self asserta: '42' = 'cuarenta y tres'.
    self assert: 'mariano' = 'esta perdido'.
    self print: 'grrrr'; cr.

.....

and only 'grrr' is printed. The TWO previous assert are ignored.

I may be doing something very stupid...

thanks in advance,

Mariano



On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:

On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:
> I've just commited the fix, but not the comment ;)
>
> Seriously, I don't know how we can document this kind of things.
> Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
> doesn't make sense because they are aprox. 12 implementaions...I don't want
> to copy paste to all of them. Only in one? it doesn't make sense because
> people won't see it. So..how we document this kind of things?  I have no
> idea.
>
> The same with class comments. There are so many classes that copy pasting or
> documenting only one doesn't make sense.
>

The root class is enough.
A subclasses should just say something like 'i am special for
___that__ and do things differently because i want __that__'.


> The only thing I though is doing something like this:
>
>
> compilerFlagsRelease
>     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
> '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
> '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
> '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
> '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
> '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
> '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
> '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>
>>>debugVMFlagEnable: boolean
> "THIS flag is blagh...blh..."
> ^ '-DDEBUGVM=', boolean asNumber asString
>
> or something like that...
>
>

This knowledge is important. It of course a question where to put that,
but that's exactly why i didn't wanted to use autoconf to generate
config.h file, which contains like 50 various flags,
without any clues, where these flags being used, and in what
situations they should be turned on or off..

So, later we could step over every flag and properly document them,
and like that, for people who will come later, we will have an idea
what are need to deal with and why.

> cheers
>
> Mariano
>

--
Best regards,
Igor Stasenko AKA sig.



--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko

On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>
> Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>
> add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>

AFAIK, code checks

#ifdef NDEBUG


which means
'if defined NDEBUG'

and so it doesn't matters if it = 1 or = 0
because it is defined, but don't cares which value.

Also,
NDEBUG and DEBUGVM should be mutually exclusive?

If first stands for 'no-debug'  and second stands for 'debug vm'..


> I modified the StackInterpreter to this:
>
> lookupMethodInClass: class
>     | currentClass dictionary found |
>     <inline: false>
>     self asserta: '42' = 'cuarenta y tres'.
>     self assert: 'mariano' = 'esta perdido'.
>     self print: 'grrrr'; cr.
>
> .....
>
> and only 'grrr' is printed. The TWO previous assert are ignored.
>
> I may be doing something very stupid...
>
> thanks in advance,
>
> Mariano
>
>
>
> On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:
>> > I've just commited the fix, but not the comment ;)
>> >
>> > Seriously, I don't know how we can document this kind of things.
>> > Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
>> > doesn't make sense because they are aprox. 12 implementaions...I don't want
>> > to copy paste to all of them. Only in one? it doesn't make sense because
>> > people won't see it. So..how we document this kind of things?  I have no
>> > idea.
>> >
>> > The same with class comments. There are so many classes that copy pasting or
>> > documenting only one doesn't make sense.
>> >
>>
>> The root class is enough.
>> A subclasses should just say something like 'i am special for
>> ___that__ and do things differently because i want __that__'.
>>
>>
>> > The only thing I though is doing something like this:
>> >
>> >
>> > compilerFlagsRelease
>> >     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
>> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
>> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
>> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
>> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
>> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
>> > '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
>> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>> >
>> >>>debugVMFlagEnable: boolean
>> > "THIS flag is blagh...blh..."
>> > ^ '-DDEBUGVM=', boolean asNumber asString
>> >
>> > or something like that...
>> >
>> >
>>
>> This knowledge is important. It of course a question where to put that,
>> but that's exactly why i didn't wanted to use autoconf to generate
>> config.h file, which contains like 50 various flags,
>> without any clues, where these flags being used, and in what
>> situations they should be turned on or off..
>>
>> So, later we could step over every flag and properly document them,
>> and like that, for people who will come later, we will have an idea
>> what are need to deal with and why.
>>
>> > cheers
>> >
>> > Mariano
>> >
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Eliot Miranda-2
 


On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:

On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>
> Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>
> add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>

AFAIK, code checks

#ifdef NDEBUG


which means
'if defined NDEBUG'

and so it doesn't matters if it = 1 or = 0
because it is defined, but don't cares which value.

Also,
NDEBUG and DEBUGVM should be mutually exclusive?

NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.

DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.

I said all this last week.  Please take note this time :)

best,
Eliot


If first stands for 'no-debug'  and second stands for 'debug vm'..


> I modified the StackInterpreter to this:
>
> lookupMethodInClass: class
>     | currentClass dictionary found |
>     <inline: false>
>     self asserta: '42' = 'cuarenta y tres'.
>     self assert: 'mariano' = 'esta perdido'.
>     self print: 'grrrr'; cr.
>
> .....
>
> and only 'grrr' is printed. The TWO previous assert are ignored.
>
> I may be doing something very stupid...
>
> thanks in advance,
>
> Mariano
>
>
>
> On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:
>> > I've just commited the fix, but not the comment ;)
>> >
>> > Seriously, I don't know how we can document this kind of things.
>> > Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
>> > doesn't make sense because they are aprox. 12 implementaions...I don't want
>> > to copy paste to all of them. Only in one? it doesn't make sense because
>> > people won't see it. So..how we document this kind of things?  I have no
>> > idea.
>> >
>> > The same with class comments. There are so many classes that copy pasting or
>> > documenting only one doesn't make sense.
>> >
>>
>> The root class is enough.
>> A subclasses should just say something like 'i am special for
>> ___that__ and do things differently because i want __that__'.
>>
>>
>> > The only thing I though is doing something like this:
>> >
>> >
>> > compilerFlagsRelease
>> >     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
>> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
>> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
>> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
>> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
>> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
>> > '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
>> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>> >
>> >>>debugVMFlagEnable: boolean
>> > "THIS flag is blagh...blh..."
>> > ^ '-DDEBUGVM=', boolean asNumber asString
>> >
>> > or something like that...
>> >
>> >
>>
>> This knowledge is important. It of course a question where to put that,
>> but that's exactly why i didn't wanted to use autoconf to generate
>> config.h file, which contains like 50 various flags,
>> without any clues, where these flags being used, and in what
>> situations they should be turned on or off..
>>
>> So, later we could step over every flag and properly document them,
>> and like that, for people who will come later, we will have an idea
>> what are need to deal with and why.
>>
>> > cheers
>> >
>> > Mariano
>> >
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Stefan Marr
In reply to this post by Mariano Martinez Peck

Hi Mariano:


On 26 Apr 2011, at 02:05, Mariano Martinez Peck wrote:

> Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>
> -DNDEBUG=1

I think Igor and Eliot already answered the question, but since nobody pointed you at this document, I will do it. Might help for future questions:

  http://linux.die.net/man/3/assert


Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 


On Tue, Apr 26, 2011 at 7:56 AM, Stefan Marr <[hidden email]> wrote:

Hi Mariano:


On 26 Apr 2011, at 02:05, Mariano Martinez Peck wrote:

> Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>
> -DNDEBUG=1

I think Igor and Eliot already answered the question,

Hi Stefan. No, they didn't answer, or yes, they answer but I am so newbie that I don't see it. My question was why I didn't see in the gdb console those outputs of those asserts. If I am compiling with -DNDEBUG=1  I expect the asserts() to be evaluating. And even more, asserta() seems to evaluates always. So...why if I did this:


lookupMethodInClass: class
    | currentClass dictionary found |
    <inline: false>
    self asserta: '42' = 'cuarenta y tres'.
    self assert: 'mariano' = 'esta perdido'.
    self print: 'grrrr'; cr.
.....

and compile the vm and I fire up an iamge...why only 'grrr' is printed ??   The TWO previous assert are ignored, even the asserta()

If this was answered I thanks someone that could explain it again for me :)

thanks in advance

Mariano

 
but since nobody pointed you at this document, I will do it. Might help for future questions:

 http://linux.die.net/man/3/assert


Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Stefan Marr

Hi Mariano:

On 26 Apr 2011, at 09:53, Mariano Martinez Peck wrote:

> If I am compiling with -DNDEBUG=1  I expect the asserts() to be evaluating.
NDEBUG is a short form for NO debug, I suppose.
Let me cite the manpage:

>>
If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all.
<<

Thus, -DNDEBUG=0 and -DNDEBUG=1, as well as -DNDEBUG=foo have all the same effect: NO DEBUG, no assertions.


>  And even more, asserta() seems to evaluates always.

I don't know asserta(), I suppose it is `assert always`?
The only thing I can tell you here is, that you probably need to refer to its implementation.

Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 


On Tue, Apr 26, 2011 at 10:18 AM, Stefan Marr <[hidden email]> wrote:

Hi Mariano:

On 26 Apr 2011, at 09:53, Mariano Martinez Peck wrote:

> If I am compiling with -DNDEBUG=1  I expect the asserts() to be evaluating.
NDEBUG is a short form for NO debug, I suppose.
Let me cite the manpage:

>>
If the macro NDEBUG was defined at the moment <assert.h> was last included, the macro assert() generates no code, and hence does nothing at all.
<<

Thus, -DNDEBUG=0 and -DNDEBUG=1, as well as -DNDEBUG=foo have all the same effect: NO DEBUG, no assertions.


Thanks Stefan. In fact, you were right. If I DO NOT define DNDEBUG, assertions. If I define it (with whatever value), no assertions.   Now, I think that I was to naive to understand Eliot's first answer:

"
NDEBUG is a Mac OS X/FreeBSD/Linux flag that controls asserts.  To get asserts working in Cog it was easiest to use this flag.  So if NDEBUG=0 asserts are eliminated and if NDEBUG=1 they are included and cause a warning to be printed to stdout when enabled (via a call to warning).  See platforms/Cross/vm/sqAssert.h.  Hence NDEBUG=0 for production and NDEBUG=1 for debug and assert VMs.
"

So..I should have NOT understood them literal  "Hence NDEBUG=0 for production and NDEBUG=1 for debug"  but  instead that for debug I DO NOT have to define NDEBUG  but I do for production ? 
 
And even more, when Igor said "and so it doesn't matters if it = 1 or = 0
because it is defined, but don't cares which value."  he was correct.


>  And even more, asserta() seems to evaluates always.

I don't know asserta(), I suppose it is `assert always`?
The only thing I can tell you here is, that you probably need to refer to its implementation.


yes

Thanks Stefan

Mariano
 
Best regards
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko
In reply to this post by Eliot Miranda-2

On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>> >
>> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>> >
>> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>> >
>>
>> AFAIK, code checks
>>
>> #ifdef NDEBUG
>>
>>
>> which means
>> 'if defined NDEBUG'
>>
>> and so it doesn't matters if it = 1 or = 0
>> because it is defined, but don't cares which value.
>>
>> Also,
>> NDEBUG and DEBUGVM should be mutually exclusive?
>
> NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
> DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.
> I said all this last week.  Please take note this time :)


But hey, i insist that they are mutually exclusive. See, if i want to
build a debug version of VM, i should use
-DDEBUGVM=1
but should not use
-DNDEBUG
because otherwise all assertions will be suppressed, which is not what
i would want in debug version of VM.


AFAIK, windows also using NDEBUG,
but my main comment was about that it is used wrongly.

The check

if defined(NDEBUG)

will always pass whether you use -DNDEBUG=1 or -DNDEBUG=0

because it checks if given symbol are defined, it doesn't cares about
its value!!!

So, a proper use would be to either omit -DNDEBUG at all, or
include it. But not like currently, changing its value between 0 or 1.


Here the code from assert.h:

#ifdef NDEBUG
#define assert(e)       ((void)0)
#else
....


And here the sample code for testing it:

>> cat a.c

#include <stdio.h>

int main()
{

#ifdef NDEBUG
printf ("NDEBUG defined\n");
#endif

return 0;

}

Now see what happens:

gcc a.c
./a.out
<no output>

gcc -DNDEBUG=0  a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=1 a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=1 a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=ZORK a.c
./a.out
NDEBUG defined


> best,
> Eliot
>>
>> If first stands for 'no-debug'  and second stands for 'debug vm'..
>>
>>
>> > I modified the StackInterpreter to this:
>> >
>> > lookupMethodInClass: class
>> >     | currentClass dictionary found |
>> >     <inline: false>
>> >     self asserta: '42' = 'cuarenta y tres'.
>> >     self assert: 'mariano' = 'esta perdido'.
>> >     self print: 'grrrr'; cr.
>> >
>> > .....
>> >
>> > and only 'grrr' is printed. The TWO previous assert are ignored.
>> >
>> > I may be doing something very stupid...
>> >
>> > thanks in advance,
>> >
>> > Mariano
>> >
>> >
>> >
>> > On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:
>> >> > I've just commited the fix, but not the comment ;)
>> >> >
>> >> > Seriously, I don't know how we can document this kind of things.
>> >> > Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
>> >> > doesn't make sense because they are aprox. 12 implementaions...I don't want
>> >> > to copy paste to all of them. Only in one? it doesn't make sense because
>> >> > people won't see it. So..how we document this kind of things?  I have no
>> >> > idea.
>> >> >
>> >> > The same with class comments. There are so many classes that copy pasting or
>> >> > documenting only one doesn't make sense.
>> >> >
>> >>
>> >> The root class is enough.
>> >> A subclasses should just say something like 'i am special for
>> >> ___that__ and do things differently because i want __that__'.
>> >>
>> >>
>> >> > The only thing I though is doing something like this:
>> >> >
>> >> >
>> >> > compilerFlagsRelease
>> >> >     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
>> >> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
>> >> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
>> >> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
>> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
>> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
>> >> > '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
>> >> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>> >> >
>> >> >>>debugVMFlagEnable: boolean
>> >> > "THIS flag is blagh...blh..."
>> >> > ^ '-DDEBUGVM=', boolean asNumber asString
>> >> >
>> >> > or something like that...
>> >> >
>> >> >
>> >>
>> >> This knowledge is important. It of course a question where to put that,
>> >> but that's exactly why i didn't wanted to use autoconf to generate
>> >> config.h file, which contains like 50 various flags,
>> >> without any clues, where these flags being used, and in what
>> >> situations they should be turned on or off..
>> >>
>> >> So, later we could step over every flag and properly document them,
>> >> and like that, for people who will come later, we will have an idea
>> >> what are need to deal with and why.
>> >>
>> >> > cheers
>> >> >
>> >> > Mariano
>> >> >
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Eliot Miranda-2
 


On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote:

On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>> >
>> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>> >
>> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>> >
>>
>> AFAIK, code checks
>>
>> #ifdef NDEBUG
>>
>>
>> which means
>> 'if defined NDEBUG'
>>
>> and so it doesn't matters if it = 1 or = 0
>> because it is defined, but don't cares which value.
>>
>> Also,
>> NDEBUG and DEBUGVM should be mutually exclusive?
>
> NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
> DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.
> I said all this last week.  Please take note this time :)


But hey, i insist that they are mutually exclusive.

You can insist all you like but you're wrong.  NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM.  Simple as that.  They are *not* mutually exclusive.
 
See, if i want to
build a debug version of VM, i should use
-DDEBUGVM=1
but should not use
-DNDEBUG
because otherwise all assertions will be suppressed, which is not what
i would want in debug version of VM.


AFAIK, windows also using NDEBUG,
but my main comment was about that it is used wrongly.

The check

if defined(NDEBUG)

will always pass whether you use -DNDEBUG=1 or -DNDEBUG=0

because it checks if given symbol are defined, it doesn't cares about
its value!!!

So, a proper use would be to either omit -DNDEBUG at all, or
include it. But not like currently, changing its value between 0 or 1.


Here the code from assert.h:

#ifdef NDEBUG
#define assert(e)       ((void)0)
#else
....


And here the sample code for testing it:

>> cat a.c

#include <stdio.h>

int main()
{

#ifdef NDEBUG
printf ("NDEBUG defined\n");
#endif

return 0;

}

Now see what happens:

gcc a.c
./a.out
<no output>

gcc -DNDEBUG=0  a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=1 a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=1 a.c
./a.out
NDEBUG defined

gcc -DNDEBUG=ZORK a.c
./a.out
NDEBUG defined


> best,
> Eliot
>>
>> If first stands for 'no-debug'  and second stands for 'debug vm'..
>>
>>
>> > I modified the StackInterpreter to this:
>> >
>> > lookupMethodInClass: class
>> >     | currentClass dictionary found |
>> >     <inline: false>
>> >     self asserta: '42' = 'cuarenta y tres'.
>> >     self assert: 'mariano' = 'esta perdido'.
>> >     self print: 'grrrr'; cr.
>> >
>> > .....
>> >
>> > and only 'grrr' is printed. The TWO previous assert are ignored.
>> >
>> > I may be doing something very stupid...
>> >
>> > thanks in advance,
>> >
>> > Mariano
>> >
>> >
>> >
>> > On Wed, Apr 13, 2011 at 8:06 PM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 13 April 2011 19:13, Mariano Martinez Peck <[hidden email]> wrote:
>> >> > I've just commited the fix, but not the comment ;)
>> >> >
>> >> > Seriously, I don't know how we can document this kind of things.
>> >> > Putting such comments in #compilerFlagsRelease  or #compilerFlagsRelease
>> >> > doesn't make sense because they are aprox. 12 implementaions...I don't want
>> >> > to copy paste to all of them. Only in one? it doesn't make sense because
>> >> > people won't see it. So..how we document this kind of things?  I have no
>> >> > idea.
>> >> >
>> >> > The same with class comments. There are so many classes that copy pasting or
>> >> > documenting only one doesn't make sense.
>> >> >
>> >>
>> >> The root class is enough.
>> >> A subclasses should just say something like 'i am special for
>> >> ___that__ and do things differently because i want __that__'.
>> >>
>> >>
>> >> > The only thing I though is doing something like this:
>> >> >
>> >> >
>> >> > compilerFlagsRelease
>> >> >     ^#('-g3' '-Os' '-fvisibility=hidden' '-funroll-loops' '-fasm-blocks'
>> >> > '-finline-functions' '-mfpmath=sse' '-fomit-frame-pointer'
>> >> > '-march=pentium-m' '-mtune=prescott' '-falign-functions=16' '-fno-gcse'
>> >> > '-fno-cse-follow-jumps' '-std=gnu99' '-DBUILD_FOR_OSX'
>> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DLSB_FIRST'
>> >> > '-DUSE_INLINE_MEMORY_ACCESSORS' '-DHAVE_SYS_TIME_H' '-DHAVE_NANOSLEEP'
>> >> > '-DNDEBUG=0' , self debugVMFlag: true,  '-DCOGMTVM=0'
>> >> > '-DUSE_GLOBAL_STRUCT=0' '-DBASE_HEADER_SIZE=4')
>> >> >
>> >> >>>debugVMFlagEnable: boolean
>> >> > "THIS flag is blagh...blh..."
>> >> > ^ '-DDEBUGVM=', boolean asNumber asString
>> >> >
>> >> > or something like that...
>> >> >
>> >> >
>> >>
>> >> This knowledge is important. It of course a question where to put that,
>> >> but that's exactly why i didn't wanted to use autoconf to generate
>> >> config.h file, which contains like 50 various flags,
>> >> without any clues, where these flags being used, and in what
>> >> situations they should be turned on or off..
>> >>
>> >> So, later we could step over every flag and properly document them,
>> >> and like that, for people who will come later, we will have an idea
>> >> what are need to deal with and why.
>> >>
>> >> > cheers
>> >> >
>> >> > Mariano
>> >> >
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Igor Stasenko

On 26 April 2011 19:01, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>> >> >
>> >> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>> >> >
>> >> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>> >> >
>> >>
>> >> AFAIK, code checks
>> >>
>> >> #ifdef NDEBUG
>> >>
>> >>
>> >> which means
>> >> 'if defined NDEBUG'
>> >>
>> >> and so it doesn't matters if it = 1 or = 0
>> >> because it is defined, but don't cares which value.
>> >>
>> >> Also,
>> >> NDEBUG and DEBUGVM should be mutually exclusive?
>> >
>> > NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
>> > DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.
>> > I said all this last week.  Please take note this time :)
>>
>>
>> But hey, i insist that they are mutually exclusive.
>
> You can insist all you like but you're wrong.  NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM.  Simple as that.  They are *not* mutually exclusive.
>

Eliot, i understand this stuff. Now you taking my words too literally.
I meant to say that for existing cmake configurations they should be
mutually exclusive.

But for current variants for release we should have:
 a) turn debugging off  (-DDEBUGVM=0)
 b) suppress assertions (-DNDEBUG)

and when building VM for debugging we doing otherwise:
 - turn all debugging on (-DDEBUGVM=1)
 - enable assertions (omit defining -DNDEBUG)

so in the above two configurations its easy to see that these two
options are mutually exclusive.

And of course, in case of need, one can create configuration where you
can use different combination of these two flags, but the above two is
most logical choice for release and debug versions of VM configs.


--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Eliot Miranda-2
 


On Tue, Apr 26, 2011 at 10:29 AM, Igor Stasenko <[hidden email]> wrote:

On 26 April 2011 19:01, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>> >> >
>> >> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>> >> >
>> >> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>> >> >
>> >>
>> >> AFAIK, code checks
>> >>
>> >> #ifdef NDEBUG
>> >>
>> >>
>> >> which means
>> >> 'if defined NDEBUG'
>> >>
>> >> and so it doesn't matters if it = 1 or = 0
>> >> because it is defined, but don't cares which value.
>> >>
>> >> Also,
>> >> NDEBUG and DEBUGVM should be mutually exclusive?
>> >
>> > NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
>> > DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.
>> > I said all this last week.  Please take note this time :)
>>
>>
>> But hey, i insist that they are mutually exclusive.
>
> You can insist all you like but you're wrong.  NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM.  Simple as that.  They are *not* mutually exclusive.
>

Eliot, i understand this stuff. Now you taking my words too literally.
I meant to say that for existing cmake configurations they should be
mutually exclusive.

Ah, agreed :)  Sorry :)
 

But for current variants for release we should have:
 a) turn debugging off  (-DDEBUGVM=0)
 b) suppress assertions (-DNDEBUG)

and when building VM for debugging we doing otherwise:
 - turn all debugging on (-DDEBUGVM=1)
 - enable assertions (omit defining -DNDEBUG)

so in the above two configurations its easy to see that these two
options are mutually exclusive.

And of course, in case of need, one can create configuration where you
can use different combination of these two flags, but the above two is
most logical choice for release and debug versions of VM configs.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: '-DNDEBUG=0' and '-DDEBUGVM=1'

Mariano Martinez Peck
 


On Tue, Apr 26, 2011 at 7:40 PM, Eliot Miranda <[hidden email]> wrote:
 


On Tue, Apr 26, 2011 at 10:29 AM, Igor Stasenko <[hidden email]> wrote:

On 26 April 2011 19:01, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Apr 26, 2011 at 6:21 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 26 April 2011 04:03, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 26 April 2011 03:05, Mariano Martinez Peck <[hidden email]> wrote:
>> >> >
>> >> > Hi guys. I don't know why but with CMakeVMMaker the asserts are not working.  I can see the flags are being set correct in CmakeList.txt:
>> >> >
>> >> > add_definitions(-arch i386 -mmacosx-version-min=10.5 -g3 -O0 -msse3 -funroll-loops -fasm-blocks -finline-functions -mfpmath=sse -march=pentium-m -falign-functions=16 -fno-gcse -fno-cse-follow-jumps -std=gnu99 -DBUILD_FOR_OSX -DUSE_INLINE_MEMORY_ACCESSORS -DLSB_FIRST -DHAVE_SYS_TIME_H -DHAVE_NANOSLEEP -DNDEBUG=1 -DDEBUGVM=1 -DCOGMTVM=1 -DUSE_GLOBAL_STRUCT=0 -DBASE_HEADER_SIZE=4 -DCOGVM)
>> >> >
>> >>
>> >> AFAIK, code checks
>> >>
>> >> #ifdef NDEBUG
>> >>
>> >>
>> >> which means
>> >> 'if defined NDEBUG'
>> >>
>> >> and so it doesn't matters if it = 1 or = 0
>> >> because it is defined, but don't cares which value.
>> >>
>> >> Also,
>> >> NDEBUG and DEBUGVM should be mutually exclusive?
>> >
>> > NO!!  NO!!  NO!!  [ :) ].  I said earlier, NDEBUG is a linux-ism for enabling asserts.  See /usr/include/assert.h.  So if defined(NDEBUG) assert(foo) does nothing, but if !defined(NDEBUG) assert(foo) prints a warning and in unix/linux aborts, but in Cog continues.
>> > DEBUGVM includes some extra code that allows break-pointing jumping from the interpreter into machien code.  Arguably it could be eliminated but it'll be useful when we port to new ISAs.
>> > I said all this last week.  Please take note this time :)
>>
>>
>> But hey, i insist that they are mutually exclusive.
>
> You can insist all you like but you're wrong.  NDEBUG controls assertions and these are orthogonal to the enilopmart debugging introduced by using DEBUGVM.  Simple as that.  They are *not* mutually exclusive.
>

Eliot, i understand this stuff. Now you taking my words too literally.
I meant to say that for existing cmake configurations they should be
mutually exclusive.

Ah, agreed :)  Sorry :)
 

But for current variants for release we should have:
 a) turn debugging off  (-DDEBUGVM=0)
 b) suppress assertions (-DNDEBUG)

and when building VM for debugging we doing otherwise:
 - turn all debugging on (-DDEBUGVM=1)
 - enable assertions (omit defining -DNDEBUG)



Yes, exactly. Finally I understood. So...I will commit the fix becuase now CMake confs are wrong.

Cheers

Mariano

 
so in the above two configurations its easy to see that these two
options are mutually exclusive.

And of course, in case of need, one can create configuration where you
can use different combination of these two flags, but the above two is
most logical choice for release and debug versions of VM configs.


--
Best regards,
Igor Stasenko AKA sig.





--
Mariano
http://marianopeck.wordpress.com