[Vm-dev] '-DNDEBUG=0' and '-DDEBUGVM=1'

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 26 02:03:45 UTC 2011


On Mon, Apr 25, 2011 at 6:39 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 26 April 2011 03:05, Mariano Martinez Peck <marianopeck at gmail.com>
> 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 <siguctua at gmail.com>
> wrote:
> >>
> >> On 13 April 2011 19:13, Mariano Martinez Peck <marianopeck at gmail.com>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110425/34ed4e7f/attachment-0001.htm


More information about the Vm-dev mailing list