Question regarding pragma translate_off/on , synthesis_off/on

Discussion in 'VHDL' started by suman.nandan@gmail.com, Jul 15, 2005.

  1. Guest

    Hi all,
    Can anyone tell me what should be the ideal behaviour for a
    synthesis tool regarding the pragmas translate_off/on and
    synthesis_off/on ?
    My question is, can we nest the pragmas one inside the other ?
    like say ..

    -- pragma translate_off
    -- pragma synthesis_off
    .... (some logic here)
    -- pragma synthesis_on
    -- pragma translate_on

    or

    -- pragma tranlate_off
    -- pragma synthesis_off
    ....(some logic here)
    -- pragma tranlate_on
    -- pragma synthesis_on

    I have heard that DC ignores such nesting and take the outermost
    into account. Can you tell me what is the behaviour of other tools ?

    Thanks.
    , Jul 15, 2005
    #1
    1. Advertising

  2. Hubble Guest

    Hi,

    these pragmas (actually comments) are an add-on of synthesis tools and
    completeley without standardization (to my knowledge). They should be
    used to disable warnings for code which checks parameters, but is not
    synthesizable.

    Unfortunately, they demonstrate the lack of an appropriate preprocessor
    for VHDL.

    If you want to disable/enable logic, use boolean generics and if
    statements:

    GENERIC in_synthesis: boolean:= true;
    ..

    If not in_synthesis then
    ... (some logic here)
    end If;

    When simulating, set the generic in_synthesis to false.

    The ideal behaviour of synthesis tools is not to have such pragmas
    (instead pragmas warnings_off/warnings on)

    This is completely inside the VHDL standard and should be possible in
    most cases. Nesting is no problem.

    Hubble.
    Hubble, Jul 15, 2005
    #2
    1. Advertising

  3. "Hubble" <> writes:

    <snip>

    > If you want to disable/enable logic, use boolean generics and if
    > statements:
    >
    > GENERIC in_synthesis: boolean:= true;
    > ..
    >
    > If not in_synthesis then
    > ... (some logic here)
    > end If;
    >


    I do this in a package:

    CONSTANT in_simulation : BOOLEAN := false
    --synthesis translate_off
    OR true
    --synthesis translate_on
    ;
    CONSTANT in_synthesis : BOOLEAN := NOT in_simulation;

    Then I don't have to worry about remembering to change the constant
    when I synthesize. And there's only one set of pragmas in the whole
    design to worry about.

    Cheers,
    Martin


    --

    TRW Conekt, Solihull, UK
    http://www.trw.com/conekt
    Martin Thompson, Jul 15, 2005
    #3
  4. Rob Dekker Guest

    Hi Suman,

    Verific DOES allow nesting of translate_off pragma's.
    The Verific parsers are used in some 35 EDA tools, including
    synthesis and verification tools.
    For example, Altera's Quartus II synthesis uses the Verific's parsers,
    and thus it will support translate_off nesting.

    Sometimes nesting happens legally in the standard VHDL packages, albeit
    under different 'vendor' translate_on/off pragma's.
    Verific needs to be complient with many different tools, and thus needs to
    be sensitive to many tool vendor pragma's. Thus support for nesting was needed.

    The problem with pragma's is that there is no written spec on how they should work.
    So if you can, try to avoid them.

    Rob

    <> wrote in message news:...
    > Hi all,
    > Can anyone tell me what should be the ideal behaviour for a
    > synthesis tool regarding the pragmas translate_off/on and
    > synthesis_off/on ?
    > My question is, can we nest the pragmas one inside the other ?
    > like say ..
    >
    > -- pragma translate_off
    > -- pragma synthesis_off
    > ... (some logic here)
    > -- pragma synthesis_on
    > -- pragma translate_on
    >
    > or
    >
    > -- pragma tranlate_off
    > -- pragma synthesis_off
    > ...(some logic here)
    > -- pragma tranlate_on
    > -- pragma synthesis_on
    >
    > I have heard that DC ignores such nesting and take the outermost
    > into account. Can you tell me what is the behaviour of other tools ?
    >
    > Thanks.
    >
    Rob Dekker, Jul 15, 2005
    #4
  5. Jim Lewis Guest

    Rob,
    > The problem with pragma's is that there is no written spec
    > on how they should work. So if you can, try to avoid them.


    Does Verific support the following?
    -- RTL_SYNTHESIS OFF
    -- RTL_SYNTHESIS ON

    I dispute your claim about there being no written spec.
    You will find these synthesis directives specified
    and standardized in IEEE 1076.6-1999.

    In the EDA community we have a major disconnect
    between EDA vendors, users, and standards developers.
    We need to proactively solve this problem.

    The old methodology of a group of experts collectively
    developing and publishing a standard is not working.
    The problem is that after developing new features, the
    features need to be marketed to the user community
    and then the user community needs to nag the EDA vendors
    to implement the new features.

    There is no one party that the blame can be placed on.
    Standards developers sometimes do not address users
    needs. Users do not have time to nag the EDA vendors.
    EDA vendors do not have enough revenue to benevolently
    implement features that have little value to the
    user community and, hence, their product.

    There are changes happening in the EDA standards
    community. Recently Accellera was granted rights
    by IEEE to make derivative works of the VHDL
    standard (IEEE 1076) and has formed a VHDL working
    group. While it is still in its early stages its shows
    promise of having a model that will ensure that user
    prioritized features get standardized. This in turn
    will reassure EDA vendors that their product will have
    a higher value to their users if they implement the
    newly standardized features.

    SynthWorks firmly believes in this process and has
    become a member of Accellera to support this effort.

    I urge experienced VHDL users to participate in this
    effort. I suspect that most of the the meaningful
    language revisions to VHDL will be done by the
    Accellera WG. The VHDL-200X Fast Track work, which
    is currently held up by lack of funding, has been
    submitted the Accellera WG for their consideration,
    prioritization, and funding. Currently funding is
    necessary to fund the task of LRM writing.

    While non-members of Accellera do not have an official
    vote, you do have influence in the form that well
    thought out discussions are generally given
    consideration. One way to look at it is there are
    very few organizations of this type that will turn
    away free labor.

    Best Regards,
    Jim Lewis
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Jul 16, 2005
    #5
  6. Rob Dekker Guest

    "Jim Lewis" <> wrote in message news:...
    > Rob,
    >> The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.

    >
    > Does Verific support the following?
    > -- RTL_SYNTHESIS OFF
    > -- RTL_SYNTHESIS ON
    >


    No, we don't. Mainly because these are never used by HDL designers.
    Why support something that is not used, and for which there is already
    an existing solution ?

    We support pragma's which are used in real life EDA tools :
    -- <pragma_trigger> translate_off
    -- <pragma_trigger> translate off

    <pragma_trigger> by default includes the defacto standard vendor names.
    This was the template used by all vendors, and there is/was no need to change that.

    But even for the RTL_SYNTHESIS OFF pragma, there is no definition
    of hiw to deal with nesting (and with mixing-in existing pragma's).

    > I dispute your claim about there being no written spec.
    > You will find these synthesis directives specified
    > and standardized in IEEE 1076.6-1999.


    I was involved in the 1076.6 working group, back in the early 90s.

    The charter of 1076.6 was honest and and well-intended,
    but I think that the effectiveness of the the group
    was greatly compromized when
    (1) Synopsys walked out, and
    (2) the group started to re-invent new stuff rather than
    focus on defining behavior of existing industry standards
    (such as pragma's), for backward compatibility, and
    (3) it costs $100 just to get a copy of the work group results.

    >
    > In the EDA community we have a major disconnect
    > between EDA vendors, users, and standards developers.
    > We need to proactively solve this problem.
    >
    > The old methodology of a group of experts collectively
    > developing and publishing a standard is not working.
    > The problem is that after developing new features, the
    > features need to be marketed to the user community
    > and then the user community needs to nag the EDA vendors
    > to implement the new features.
    >
    > There is no one party that the blame can be placed on.
    > Standards developers sometimes do not address users
    > needs. Users do not have time to nag the EDA vendors.
    > EDA vendors do not have enough revenue to benevolently
    > implement features that have little value to the
    > user community and, hence, their product.
    >
    > There are changes happening in the EDA standards
    > community. Recently Accellera was granted rights
    > by IEEE to make derivative works of the VHDL
    > standard (IEEE 1076) and has formed a VHDL working
    > group. While it is still in its early stages its shows
    > promise of having a model that will ensure that user
    > prioritized features get standardized. This in turn
    > will reassure EDA vendors that their product will have
    > a higher value to their users if they implement the
    > newly standardized features.
    >
    > SynthWorks firmly believes in this process and has
    > become a member of Accellera to support this effort.
    >
    > I urge experienced VHDL users to participate in this
    > effort. I suspect that most of the the meaningful
    > language revisions to VHDL will be done by the
    > Accellera WG. The VHDL-200X Fast Track work, which
    > is currently held up by lack of funding, has been
    > submitted the Accellera WG for their consideration,
    > prioritization, and funding. Currently funding is
    > necessary to fund the task of LRM writing.
    >
    > While non-members of Accellera do not have an official
    > vote, you do have influence in the form that well
    > thought out discussions are generally given
    > consideration. One way to look at it is there are
    > very few organizations of this type that will turn
    > away free labor.
    >
    > Best Regards,
    > Jim Lewis
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    Rob Dekker, Jul 18, 2005
    #6
  7. Jim Lewis Guest

    Rob,
    >>>The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.

    >>
    >>Does Verific support the following?
    >>-- RTL_SYNTHESIS OFF
    >>-- RTL_SYNTHESIS ON
    >>

    >
    >
    > No, we don't.


    Not surprising as I don't think anyone does.
    The point of my question was to illustrate that
    the process of standards being made by benevolent
    experts does not always work well.


    > No, we don't. Mainly because these are never used by HDL designers.
    > Why support something that is not used, and for which there is already
    > an existing solution ?


    This illustrates the classic stand-off:
    Vendors: Why implement a new feature if no-one uses it.
    Users: Why use a new feature if not all the vendors in
    my current design flow implement it.

    Without devine intervention, this process will never work.


    > We support pragma's which are used in real life EDA tools :
    > -- <pragma_trigger> translate_off
    > -- <pragma_trigger> translate off
    >
    > <pragma_trigger> by default includes the defacto standard vendor names.
    > This was the template used by all vendors, and there is/was no need to change that.


    You are right.

    To be fair, 1076.6 was developed in the time frame between
    1996 and 1998 and the only common pragma trigger that
    I was aware of was "-- synopsys". I think "-- pragma"
    either came out during the same time or a little later.

    The WG chose the pragma trigger "RTL_SYNTHESIS".
    One reason was to differentiate RTL from behavioral
    synthesis. Since VHDL was taking so much abuse about
    having long names, rather than translate_off and
    translate_on it was shortened to OFF and ON.

    Based on your template, the IEEE pragma would adds the
    format:
    -- <pragma_trigger> off

    This does not seem unreasonable or difficult to implement.
    We would only need one flavor if all tools supported the
    same one.


    Also note that if the standard is broken there is
    no reason not to fix it.


    > But even for the RTL_SYNTHESIS OFF pragma, there is no definition
    > of hiw to deal with nesting (and with mixing-in existing pragma's).


    True. Have you submitted a issue report with respect to this?
    ISAC is alive and working to make sure all issues get forwarded
    to the right place and so they can be worked on.


    > I was involved in the 1076.6 working group, back in the early 90s.


    Since your product is integrated into 35 vendor tools,
    you really should be part of the current standards process.

    My main point is that we have a new standards organization
    called Accellera. They are working hard to create standards
    that represent user priorities. Users will want to use
    these features. Your wisdom will certainly help us create
    something better than we could without you. Furthermore,
    if cost is an issue, non-members can participate, they just
    can't have an official vote on all items. Note that this
    year VHDL has lots of work that needs to get done so anything
    you can do to help funding would be greatly appreciated.

    Best Regards,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Jul 19, 2005
    #7
  8. Eric DELAGE Guest

    > > We support pragma's which are used in real life EDA tools :
    > > -- <pragma_trigger> translate_off
    > > -- <pragma_trigger> translate off
    > >
    > > <pragma_trigger> by default includes the defacto standard vendor names.
    > > This was the template used by all vendors, and there is/was no need to
    > > change that.

    >
    > You are right.


    You're wrong. I develop VHDL code for multiple VHDL compilers from
    Xilinx, Synopsys and Synplicity. According to your convention, I
    should write:

    -- synopsys translate_off
    -- xilinx translate_off
    -- synplicity translate_off
    .... my code ...
    -- synplicity translate_on
    -- xilinx translate_on
    -- synopsys translate_on

    If now, I want to compile my VHDL code for Altera and use its Quartus
    compiler, I should look for the pragmas in all my VHDL files and add
    your --altera translate_off/_on. Honestly, I think that you miss the
    point for standardization ;-)

    It's funny to know that Synplicity supports the -- SYNOPSYS pragmas
    and that Synopsys supports the standardized -- RTL SYNTHESIS_ON/_OFF
    ones (as well as the -- SYNOPSYS). In this mess, I would rather
    suggest to use:

    -- RTL SYNTHESIS_OFF
    -- <your vendor @ a point in time> TRANSLATE_OFF
    .... my code ...
    -- <your vendor @ a point in time> TRANSLATE_ON
    -- RTL SYNTHESIS_ON

    and to put your EDA vendor under high pressure to add the official
    standardized pragmas in its VHDL parser. Designers are responsible for
    informing them again and again on their needs incl. their need for
    standardization.

    Eric
    Eric DELAGE, Jul 19, 2005
    #8
  9. Rob Dekker Guest

    "Eric DELAGE" <> wrote in message news:...
    >> > We support pragma's which are used in real life EDA tools :
    >> > -- <pragma_trigger> translate_off
    >> > -- <pragma_trigger> translate off
    >> >
    >> > <pragma_trigger> by default includes the defacto standard vendor names.
    >> > This was the template used by all vendors, and there is/was no need to
    >> > change that.

    >>
    >> You are right.

    >
    > You're wrong. I develop VHDL code for multiple VHDL compilers from
    > Xilinx, Synopsys and Synplicity. According to your convention, I
    > should write:
    >
    > -- synopsys translate_off
    > -- xilinx translate_off
    > -- synplicity translate_off
    > ... my code ...
    > -- synplicity translate_on
    > -- xilinx translate_on
    > -- synopsys translate_on


    Yeah, it's a mess out there.
    But you won't need to (and should not) enumerate all vendors in your translate_off pragma's.

    Apart from the vendor-specific pragma's the 'general' form of the pragma is
    -- synthesis translate_off
    -- synthesis translate_on

    Since the purpose of the pragma is to let a synthesis tool ignore certain
    portions of text, this seems the most obvious pragma.
    I believe this is supported by all vendors.

    Also, -- pragma translate_off is pretty much a general defacto-standard,

    >
    > If now, I want to compile my VHDL code for Altera and use its Quartus
    > compiler, I should look for the pragmas in all my VHDL files and add
    > your --altera translate_off/_on. Honestly, I think that you miss the
    > point for standardization ;-)


    Frankly I don't see how standardization could help here.
    There will always be vendors which want their own pragma's, to offer
    immediate work-arounds for problems with their tool in customer designs.
    Many of these pragma's are really intended for that specific tool only.
    So, as a user, just avoid these as the plague !

    >
    > It's funny to know that Synplicity supports the -- SYNOPSYS pragmas
    > and that Synopsys supports the standardized -- RTL SYNTHESIS_ON/_OFF
    > ones (as well as the -- SYNOPSYS). In this mess, I would rather
    > suggest to use:
    >
    > -- RTL SYNTHESIS_OFF
    > -- <your vendor @ a point in time> TRANSLATE_OFF
    > ... my code ...
    > -- <your vendor @ a point in time> TRANSLATE_ON
    > -- RTL SYNTHESIS_ON


    You just invented yet another pragma-trigger : -- RTL
    I don't think that is a good idea.

    Also, since pragma 'nesting' is not necessarily supported by some
    tool vendors, you might want to avoid this too.

    >
    > and to put your EDA vendor under high pressure to add the official
    > standardized pragmas in its VHDL parser. Designers are responsible for
    > informing them again and again on their needs incl. their need for
    > standardization.


    I think it is much easier to follow the de-facto standard :
    -- synthesis translate_off is your standard for text off/on pragma's.

    Apart from that, just ask your vendor if the tool is Verific-complient.
    Much easier than trying to push for a pragma standard.

    Thanks for your input !

    >
    > Eric
    Rob Dekker, Jul 20, 2005
    #9
  10. Rob Dekker Guest

    "Jim Lewis" <> wrote in message news:...
    > Rob,
    >>>>The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.
    >>>
    >>>Does Verific support the following?
    >>>-- RTL_SYNTHESIS OFF
    >>>-- RTL_SYNTHESIS ON
    >>>

    >>
    >> No, we don't.

    >
    > Not surprising as I don't think anyone does.
    > The point of my question was to illustrate that
    > the process of standards being made by benevolent
    > experts does not always work well.
    >


    I understand. And it did not for this pragma, and other 1076.6 'synthesis' features.

    But it did work for VHDL itself !!
    The 1076 87 and 93 standards are so complete and accurate,
    that there is virtually no way for a tool builder to 'hide' behind LRM ambiguities,
    and in turn this greatly enhanced tool-interoperatebility.

    >
    >> No, we don't. Mainly because these are never used by HDL designers.
    >> Why support something that is not used, and for which there is already
    >> an existing solution ?

    >
    > This illustrates the classic stand-off:
    > Vendors: Why implement a new feature if no-one uses it.
    > Users: Why use a new feature if not all the vendors in
    > my current design flow implement it.
    >
    > Without devine intervention, this process will never work.
    >


    Right.
    If translate_off pragma's is all that we talk about, then I think that with VHDL,
    the process is nicely under control, caused by the tight and
    unambiguous VHDL standards.

    The situation is MUCH worse for Verilog...

    >
    >> We support pragma's which are used in real life EDA tools :
    >> -- <pragma_trigger> translate_off
    >> -- <pragma_trigger> translate off
    >>
    >> <pragma_trigger> by default includes the defacto standard vendor names.
    >> This was the template used by all vendors, and there is/was no need to change that.

    >
    > You are right.
    >
    > To be fair, 1076.6 was developed in the time frame between
    > 1996 and 1998 and the only common pragma trigger that
    > I was aware of was "-- synopsys". I think "-- pragma"
    > either came out during the same time or a little later.
    >
    > The WG chose the pragma trigger "RTL_SYNTHESIS".
    > One reason was to differentiate RTL from behavioral
    > synthesis. Since VHDL was taking so much abuse about
    > having long names, rather than translate_off and
    > translate_on it was shortened to OFF and ON.
    >
    > Based on your template, the IEEE pragma would adds the
    > format:
    > -- <pragma_trigger> off
    >
    > This does not seem unreasonable or difficult to implement.
    > We would only need one flavor if all tools supported the
    > same one.
    >


    It's not difficult to implement, but we are not solving a problem here.
    How many ways do we need to exclude text for a tool ?
    Just use -- synthesis translate_off

    >
    > Also note that if the standard is broken there is
    > no reason not to fix it.
    >


    If you want to persue this for a standards change, then I seriously
    recommend to change it to -- synthesis translate_off

    If you want, could you also propose a standard for the
    real pragma's ? The ones that define a synthesis implementation for
    VHDL functions ? Things like :

    -- pragma map_to_operator SUB_UNS_OP
    -- pragma type_function LEFT_UNSIGNED_ARG

    There is a far greater veriety there than on the translate_off pragma

    Problem with pragma's :

    The cat is already out of the bag.
    Tool builders need to support existing functionality, and thus at this point
    (18 years after the standard came out), it fruitless to start an additional
    standardization process.

    >
    >> But even for the RTL_SYNTHESIS OFF pragma, there is no definition of hiw to deal with nesting (and with mixing-in existing
    >> pragma's).

    >
    > True. Have you submitted a issue report with respect to this?
    > ISAC is alive and working to make sure all issues get forwarded
    > to the right place and so they can be worked on.
    >


    No, I did not. Since there is no need for this pragma.

    I am no longer directly involved in language standardization.
    But indirectly, the Verific parsers are setting a standard by themselves.
    We are complient with all major vendors pragma's and language
    support, for a wide range of tools and applications.

    So if every vendors would use Verific, tool interoperability problems
    due to issues that we missed in the language LRM, will become less
    and less of a problem. And that helps everyone.

    >
    > > I was involved in the 1076.6 working group, back in the early 90s.

    >
    > Since your product is integrated into 35 vendor tools,
    > you really should be part of the current standards process.
    >
    > My main point is that we have a new standards organization
    > called Accellera. They are working hard to create standards
    > that represent user priorities. Users will want to use
    > these features. Your wisdom will certainly help us create
    > something better than we could without you. Furthermore,
    > if cost is an issue, non-members can participate, they just
    > can't have an official vote on all items. Note that this
    > year VHDL has lots of work that needs to get done so anything
    > you can do to help funding would be greatly appreciated.
    >


    I would like Accellera to slow down.
    Does us joining Accellera help for that ?
    System Verilog 3.1a is more than complex enough to let front-end builders
    work for a couple of years. Nobody can use it currently,
    since there is no complete 3.1a simulator yet, and most tools are lacking SV support.

    Other than that, I think that tool builders like Verific should not interfere
    too much with language features required or desired by designers.

    Languages should be driven by users, not by parser builders.
    But if there would be an efford to standardize the old (non-standardized,
    yet ultimately critical feature of) -v/-y XL options
    (library reading for Verilog 95), then I will be the first one
    to join the effort.

    We might join Accellera, or at least will issue feedback for
    existing LRM 3.1a ambiguities or incompleteness.
    We found many such issues already.

    > Best Regards,
    > Jim
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Rob Dekker, Jul 21, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ryang
    Replies:
    1
    Views:
    942
    Wes Groleau
    Apr 11, 2005
  2. Titus A Ducksass
    Replies:
    1
    Views:
    6,024
    Sid Ismail
    Aug 1, 2003
  3. venkat

    Regarding #pragma

    venkat, May 15, 2007, in forum: C Programming
    Replies:
    5
    Views:
    349
    Default User
    May 15, 2007
  4. Rob Dekker
    Replies:
    5
    Views:
    2,227
    Mike Treseler
    Mar 11, 2008
  5. Boltar

    Question about using #pragma pack

    Boltar, Mar 20, 2008, in forum: C Programming
    Replies:
    7
    Views:
    400
    Keith Thompson
    Mar 20, 2008
Loading...

Share This Page