Cipher Lab / Syntech

Discussion in 'C Programming' started by Cawas, May 15, 2007.

  1. Cawas

    Cawas Guest

    Cipher Lab produces some terminals to collect data where we can
    program using one implementation of plain C which I believe to be ANSI
    C89 compatible, although not fully. They have their on set of
    libraries as well, but all in all, it's basic C we're talking about.

    Ok, this is my first time on lots of things. I've never been to
    usenet, and I'm not much an expert of Google Groups, or IRC, and
    similar forums-thingies, with the exception of PHPBB / VBulletin PHP
    forums system, which are pretty simple content-wise.

    So I'm not sure I'm posting this in the right place, or if I even
    should be doing it here. I did my research but it'll never be as good
    as just trying it out.

    Also I did not and wish not to look for this kind of information on
    the owner's site. I believe they won't have much support, and
    certainlly not as deep as I want.

    I'm also starting working with C this year, and getting the depth of
    it as well just now (although I'm a little familiar with it since
    2000). Hopefully, at very least, I'll have some documentation done
    alone by myself, if nobody joins.

    Introductions aside, I do have lots of questions and I'd like to know
    if by any chance someone knows of a more specific place where I could
    find people that are programming for C and those terminals from Cipher
    Lab that wish to share knowledge, discuss over programming, etc.

    Particularly, I'd love to know if someone could sucessfully use any
    well known string library on it, such as Paul Hsieh's bstring (
    http://bstring.sourceforge.net ), although I doubt it. And I know for
    experience that it would be nice to share some custom made libraries
    to solve lots of troubles on those terminals, since I've been
    painfully building one myself, from scratch.

    Anyway, I'll be organizing and trying to isolate some problems I'm
    getting with the terminal and post them following in here, together
    with some functions I've been using, and may be of some use for
    someone, even if just as basic learning purpose, since I am (or at
    least feel like) still at basics myself.

    The next "topics" I'll try to bring are:
    1. strings - I think 90% of all troubles I'm having are from trying to
    manipulate them. A good simple workaround library, which does not use
    malloc, would be greatly appreciated. But maybe I'll just finish my
    own soon enough.

    2. extern volatile unsigned long sys_msec - not the sys_msec itself,
    rather trying to use it with other "unsigned long" variables. I've
    tried to isolate this problem with no success yet, so I'm even more
    intrigued in why I'm getting it in my program, which must have around
    5000 lines.

    3. void OSTimeDly (unsigned long ticks) - when creating a task with
    OSTaskCreate, it will only be activated by an OSTimeDly. This can get
    really messy to use, specially when mixing it with getchar.

    4. stdarg.h - it does not have va_copy, but I'm not having an issue
    with that. Although I'd love to see an implementation of va_copy since
    I have no idea how to write it, my problem here is on using it to
    create my own vprintf. I could create a "dprintf" that works just
    fine, but I've wanted to expand it, making a rdprintf that would use
    dprintf. For that, I need to create a vdprintf, and that's where I
    can't go beyond.

    5. speeds issues - apparently, the most demanding is to print and
    clear the screen. I've build a function to list the entries from the
    DBF files, but it's quite slow to scroll down. This is the only place
    where I've seem speed as an issue, and I'm still trying to figure out
    a way to make it smooth, although I've managed to make it
    satisfactory.

    6. select queries - this is probably just a "dream", but I did wish to
    be able to filter the above list with something at least similar to a
    SQL. For now, I just can't filter it at all. Maybe it never will.


    And that's way more than enough for now!
     
    Cawas, May 15, 2007
    #1
    1. Advertising

  2. Cawas

    Flash Gordon Guest

    Cawas wrote, On 15/05/07 21:12:
    > Cipher Lab produces some terminals to collect data where we can
    > program using one implementation of plain C which I believe to be ANSI
    > C89 compatible, although not fully. They have their on set of
    > libraries as well, but all in all, it's basic C we're talking about.


    We can't help you with the vagaries of your particular C
    implementations, but we can help you with standard C (ISO or ANSI, any
    version) and with pre-ANSI C (i.g. K&R C).

    <snip>

    > Particularly, I'd love to know if someone could sucessfully use any
    > well known string library on it, such as Paul Hsieh's bstring (
    > http://bstring.sourceforge.net ), although I doubt it.


    Paul posts here, and I'm sure he will be prepared to help you with his
    library. He can also point you at the best place to discus it.

    > And I know for
    > experience that it would be nice to share some custom made libraries
    > to solve lots of troubles on those terminals, since I've been
    > painfully building one myself, from scratch.


    Those third party libraries are not topical here either.

    <snip>

    > The next "topics" I'll try to bring are:
    > 1. strings - I think 90% of all troubles I'm having are from trying to
    > manipulate them. A good simple workaround library, which does not use
    > malloc, would be greatly appreciated. But maybe I'll just finish my
    > own soon enough.


    Any "simple" library is likely to use malloc under the hood.

    > 2. extern volatile unsigned long sys_msec - not the sys_msec itself,
    > rather trying to use it with other "unsigned long" variables. I've
    > tried to isolate this problem with no success yet, so I'm even more
    > intrigued in why I'm getting it in my program, which must have around
    > 5000 lines.


    What is your problem with it? We are not mind readers! I know that no
    one here is a mind reader because I have read everyone's minds to check!

    > 3. void OSTimeDly (unsigned long ticks) - when creating a task with
    > OSTaskCreate, it will only be activated by an OSTimeDly. This can get
    > really messy to use, specially when mixing it with getchar.


    That is non-standard so we cannot help you with it.

    > 4. stdarg.h - it does not have va_copy, but I'm not having an issue
    > with that.


    Not surprising since it was only added to the standard in 1999, and most
    compilers do not support this "new" standard.

    > Although I'd love to see an implementation of va_copy since
    > I have no idea how to write it,


    You cannot write it portably, which is probably why it was added to the
    standard. Non-portable tricks to implement it are not topical here.

    > my problem here is on using it to
    > create my own vprintf. I could create a "dprintf" that works just
    > fine, but I've wanted to expand it, making a rdprintf that would use
    > dprintf. For that, I need to create a vdprintf, and that's where I
    > can't go beyond.


    Without more information on what you are trying to do it is hard to
    offer advice. With more details we probably can help with this.

    > 5. speeds issues - apparently, the most demanding is to print and
    > clear the screen. I've build a function to list the entries from the
    > DBF files, but it's quite slow to scroll down. This is the only place
    > where I've seem speed as an issue, and I'm still trying to figure out
    > a way to make it smooth, although I've managed to make it
    > satisfactory.


    The C standard knows nothing about "DBF files" or scrolling, so this is
    not topical here.

    > 6. select queries - this is probably just a "dream", but I did wish to
    > be able to filter the above list with something at least similar to a
    > SQL. For now, I just can't filter it at all. Maybe it never will.


    There are SQL libraries you could investigate, such as sqlite, but they
    are not topical here.
    --
    Flash Gordon
     
    Flash Gordon, May 15, 2007
    #2
    1. Advertising

  3. Cawas

    Richard Guest

    Flash Gordon <> writes:

    > Cawas wrote, On 15/05/07 21:12:
    >> Cipher Lab produces some terminals to collect data where we can
    >> program using one implementation of plain C which I believe to be ANSI
    >> C89 compatible, although not fully. They have their on set of
    >> libraries as well, but all in all, it's basic C we're talking about.

    >
    > We can't help you with the vagaries of your particular C
    > implementations, but we can help you with standard C (ISO or ANSI, any
    > version) and with pre-ANSI C (i.g. K&R C).
    >
    > <snip>
    >
    >> Particularly, I'd love to know if someone could sucessfully use any
    >> well known string library on it, such as Paul Hsieh's bstring (
    >> http://bstring.sourceforge.net ), although I doubt it.

    >
    > Paul posts here, and I'm sure he will be prepared to help you with his
    > library. He can also point you at the best place to discus it.
    >
    >> And I know for
    >> experience that it would be nice to share some custom made libraries
    >> to solve lots of troubles on those terminals, since I've been
    >> painfully building one myself, from scratch.

    >
    > Those third party libraries are not topical here either.
    >
    > <snip>
    >
    >> The next "topics" I'll try to bring are:
    >> 1. strings - I think 90% of all troubles I'm having are from trying to
    >> manipulate them. A good simple workaround library, which does not use
    >> malloc, would be greatly appreciated. But maybe I'll just finish my
    >> own soon enough.

    >
    > Any "simple" library is likely to use malloc under the hood.
    >
    >> 2. extern volatile unsigned long sys_msec - not the sys_msec itself,
    >> rather trying to use it with other "unsigned long" variables. I've
    >> tried to isolate this problem with no success yet, so I'm even more
    >> intrigued in why I'm getting it in my program, which must have around
    >> 5000 lines.

    >
    > What is your problem with it? We are not mind readers! I know that no
    > one here is a mind reader because I have read everyone's minds to
    > check!
    >
    >> 3. void OSTimeDly (unsigned long ticks) - when creating a task with
    >> OSTaskCreate, it will only be activated by an OSTimeDly. This can get
    >> really messy to use, specially when mixing it with getchar.

    >
    > That is non-standard so we cannot help you with it.
    >
    >> 4. stdarg.h - it does not have va_copy, but I'm not having an issue
    >> with that.

    >
    > Not surprising since it was only added to the standard in 1999, and
    > most compilers do not support this "new" standard.
    >
    >> Although I'd love to see an implementation of va_copy since
    >> I have no idea how to write it,

    >
    > You cannot write it portably, which is probably why it was added to
    > the standard. Non-portable tricks to implement it are not topical
    > here.
    >
    >> my problem here is on using it to
    >> create my own vprintf. I could create a "dprintf" that works just
    >> fine, but I've wanted to expand it, making a rdprintf that would use
    >> dprintf. For that, I need to create a vdprintf, and that's where I
    >> can't go beyond.

    >
    > Without more information on what you are trying to do it is hard to
    > offer advice. With more details we probably can help with this.
    >
    >> 5. speeds issues - apparently, the most demanding is to print and
    >> clear the screen. I've build a function to list the entries from the
    >> DBF files, but it's quite slow to scroll down. This is the only place
    >> where I've seem speed as an issue, and I'm still trying to figure out
    >> a way to make it smooth, although I've managed to make it
    >> satisfactory.

    >
    > The C standard knows nothing about "DBF files" or scrolling, so this
    > is not topical here.
    >
    >> 6. select queries - this is probably just a "dream", but I did wish to
    >> be able to filter the above list with something at least similar to a
    >> SQL. For now, I just can't filter it at all. Maybe it never will.

    >
    > There are SQL libraries you could investigate, such as sqlite, but
    > they are not topical here.


    Do you realise you said "off topic" 7 times? Is this a new record?

    Why bother replying? It's a waste of every ones time. Probably least of
    all yours. Don't you have enough "c.l.c pedant" medals by now?
     
    Richard, May 16, 2007
    #3
  4. Richard said:

    <snip>

    > Do you realise you said "off topic" 7 times? Is this a new record?
    >
    > Why bother replying?


    So that the OP will know which parts of his query are topical and which
    not, so that he will not waste his time and ours in looking here for
    answers which he needs to seek elsewhere.

    > It's a waste of every ones time.


    No, it's an attempt to /save/ everyone's time. If you had thought this
    through properly, you would have realised that you have no point
    whatsoever and would not have bothered to reply, and /that/ would have
    saved everyone's time, too.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, May 16, 2007
    #4
  5. Cawas

    Cawas Guest

    Thanks for your prompt reply, Flash! I really was not counting with
    such attention in any answer.

    If it were not for being such a peculiar issue I would be having no
    problems finding answers in the groups. I'm really not much a fan of
    posting repeated subjects. I see what you mean about lots of my
    questions being non-topics in here, but if I want to use google groups
    for this topic, what should I do? Create a new group under
    comp.lang.c ? I was hoping here would be a good place to ask for
    directions and instead of being vague by stopping at the first
    paragraphs, I've wanted to give specific details about it.

    I have not posted code snippets exactly because I was not sure this
    was the proper place to discuss them. And also because I need to build
    the snippets to work out of context. I am not asking for any help on
    the codes just yet, I was hoping that was clear. I just organized that
    list for myself, and as samples of what I'm looking for, as Richard
    pointed out.

    Well,
    The "simple" library without malloc is needed because I was told
    malloc is not well implemented on this terminal, and should not be
    used. I was actually using malloc in my program before, without any
    problems, but I removed all of them under that advice, and I'd like to
    keep it safe and go without it because I'm not sure why malloc could
    be such an issue for the terminal. But even using just static memory
    the regular C "string" is a pain, to mention the less.

    As for Paul, I would not bother him with this. He seems to enjoy
    problems which are much more complex and global, and I can't imagine
    myself talking at his level of computing understanding in general. I
    would be just boring for him. I cited his lib, though, because I've
    realised the effort he put behind it, and it would be nice to have
    such lib that I could use and learn from using it.

    About he item 2, it was actually the reason I've wanted to see if I
    could find some community which would share problems about this
    specific C. Looking through its libraries, it says its copyrighted to
    Toshiba, 1994.

    Anyway, since you seem eager to help, I'm expanding items 2 and 4,
    hoping they do belong here. :p

    And thanks again!

    ------
    2. unsigned long issue ?

    I'm still trying to reproduce the actual problem I'm having, but
    meanwhile I'll just describe it here. The following code works fine,
    if compiled with syntech's CC900.EXE which comes with the terminal,
    for the model CPT8100:

    In case you wonder, the 8100lib.h implements printf, and maybe all of
    stdio.h (I haven't checked it).

    #include <ucos.h>
    #include <8100lib.h>

    #define DELAY 5000 /* ms */

    unsigned long sysmsec (void) { return sys_msec * 5; }

    void foo (const unsigned long delay) {
    const unsigned long final_msec = sysmsec() + delay;
    while (sysmsec() < final_msec) {
    gotoxy(0, 7);
    printf("%ld,%ld", sysmsec()+delay, sysmsec());
    }
    }

    void bar (void) {
    foo(DELAY);
    }

    int main (void) {
    gotoxy(0, 0);
    printf("%ld", sysmsec());
    bar();

    gotoxy(0, 1);
    printf("%ld", sysmsec());
    foo(DELAY);

    return 0;
    }

    In practice, I have just "main" in a separated file (although I'm just
    using include to concatanate all separated files, instead of compiling
    them separatedly), and if I try to call the equivalent of foo(DELAY)
    the delay inside foo comes with a random gigantic value, while the
    equivalent of bar(), which has also just that one line, works just
    fine.

    The actual functions basically have more parameters. While s_read_com
    also do something, ds_read_com, the bar equivalent, just have more
    parameters. I hope it's safe to ignore ds_read_com implementation:

    int ds_read_com (int nPort, char* buff, size_t s, const char* cterm,
    const unsigned char key, const unsigned long delay);

    int s_read_com (int nPort, char* buff, size_t s, const char* cterm,
    const unsigned char key) {
    return ds_read_com(nPort, buff, s, cterm, key, DELAY_READ_COM);
    }

    I'll leave this here for now, but I think I'll have to solve it
    myself. Right now I'm doing a lot of debug on it, and I'll post here
    whenever I get it fixed, specially if I identify why it happens. I
    think I'm making some progress.


    ------
    4. stdarg.h
    For some reason, I can use vsprintf, but not vprintf, so I did this:

    int __CDECL vprintf (const char *format, va_list arg) {
    char prt[200+1];
    vsprintf(prt, format, arg);
    return puts(prt);
    }

    Keep in mind malloc is not an option. That works, but I wonder what
    would be a better way to write it.

    I really thought that something similar to the following
    implementation of dprintf and rdprintf was quite logical to deduce,
    but it never hurts to give my practical example:

    int dprintf (int mode, const char* fmt, ...) {
    va_list arglist;
    int result;
    int oldmode;
    if (mode >= 0) {
    oldmode = GetVideoMode();
    SetVideoMode(mode);
    }
    va_start(arglist, fmt);
    result = vprintf(fmt, arglist);
    va_end(arglist);
    if (mode >= 0) SetVideoMode(oldmode);
    return result;
    }

    int rdprintf (int mode, const char* fmt, ...) {
    va_list arglist;
    int result;
    int oldx = wherex();
    int oldy = wherey();
    int oldcursor = GetCursor();
    SetCursor(CURSOR_OFF);

    va_start(arglist, fmt);
    result = vdprintf(mode, fmt, arglist);
    va_end(arglist);

    gotoxy(oldx, oldy);
    SetCursor(oldcursor);
    return result;
    }


    The "mode" could be anything else and, in fact, I have many more
    parameters in dprintf. In case you wonder the letters meanings, d is
    for display, and r is for recover, because the first is for
    manipulating some display options in the terminal, and the second is
    for also recovering the previous options.

    Now, how would I write vdprintf? I am just hoping I don't need to use
    va_arg and make an interpreter for fmt, because I can imagine that
    solution, but I can also imagine how big it would be. And I also
    realize I could just re-write dprintf inside rdprintf, but that would
    be bad for further updates. It would be bad coding with really small
    price to pay, but even then I rather avoid it.
     
    Cawas, May 16, 2007
    #5
  6. Cawas

    Flash Gordon Guest

    Cawas wrote, On 16/05/07 16:03:
    > Thanks for your prompt reply, Flash! I really was not counting with
    > such attention in any answer.
    >
    > If it were not for being such a peculiar issue I would be having no
    > problems finding answers in the groups. I'm really not much a fan of
    > posting repeated subjects. I see what you mean about lots of my
    > questions being non-topics in here,


    Making a mistake is fine.

    > but if I want to use google groups
    > for this topic, what should I do?


    Firstly, this is not Google Groups. Google Groups is merely one
    interface on to a far larger thing called Usenet, something that existed
    before Google existed.

    > Create a new group under
    > comp.lang.c ?


    No. There is a procedure for creating groups, a procedure that has
    nothing to do with Google, and I doubt that you would succeed.

    I suggest you look for mailing lists dedicated to your system.

    Also, if your system is an embedded system then comp.arch.embedded may
    be able to offer some assistance.

    <snip>

    > Well,
    > The "simple" library without malloc is needed because I was told
    > malloc is not well implemented on this terminal, and should not be
    > used. I was actually using malloc in my program before, without any
    > problems, but I removed all of them under that advice, and I'd like to
    > keep it safe and go without it because I'm not sure why malloc could
    > be such an issue for the terminal. But even using just static memory
    > the regular C "string" is a pain, to mention the less.


    First rule of optimisation, don't do it. If the performance of your
    application was fine with malloc and that was the clearest way to write
    it you should have stuck with it. Something I've learnt is that many of
    the "don't do this because it is inefficient" suggestions are no longer
    relevant because technology has moved on. Also, it is easier to speed up
    a working and clearly written program than to get a fast but hard to
    read program working correctly.

    > As for Paul, I would not bother him with this. He seems to enjoy


    <snip>

    You might be surprised. He has certainly been prepared to halp on far
    simpler things.

    > About he item 2, it was actually the reason I've wanted to see if I
    > could find some community which would share problems about this
    > specific C. Looking through its libraries, it says its copyrighted to
    > Toshiba, 1994.


    With that date I would have hoped that it would conform fully to C89,
    the standard released by ANSI in 1989.

    > Anyway, since you seem eager to help, I'm expanding items 2 and 4,
    > hoping they do belong here. :p
    >
    > And thanks again!
    >
    > ------
    > 2. unsigned long issue ?
    >
    > I'm still trying to reproduce the actual problem I'm having, but
    > meanwhile I'll just describe it here. The following code works fine,
    > if compiled with syntech's CC900.EXE which comes with the terminal,
    > for the model CPT8100:
    >
    > In case you wonder, the 8100lib.h implements printf, and maybe all of
    > stdio.h (I haven't checked it).


    From the sounds of this comp.arch.embedded may well be a better place
    for initial questioning.

    > #include <ucos.h>
    > #include <8100lib.h>
    >
    > #define DELAY 5000 /* ms */
    >
    > unsigned long sysmsec (void) { return sys_msec * 5; }
    >
    > void foo (const unsigned long delay) {
    > const unsigned long final_msec = sysmsec() + delay;
    > while (sysmsec() < final_msec) {
    > gotoxy(0, 7);
    > printf("%ld,%ld", sysmsec()+delay, sysmsec());
    > }
    > }
    >
    > void bar (void) {
    > foo(DELAY);
    > }
    >
    > int main (void) {
    > gotoxy(0, 0);
    > printf("%ld", sysmsec());
    > bar();
    >
    > gotoxy(0, 1);
    > printf("%ld", sysmsec());
    > foo(DELAY);
    >
    > return 0;
    > }
    >
    > In practice, I have just "main" in a separated file (although I'm just
    > using include to concatanate all separated files, instead of compiling
    > them separatedly), and if I try to call the equivalent of foo(DELAY)
    > the delay inside foo comes with a random gigantic value, while the
    > equivalent of bar(), which has also just that one line, works just
    > fine.


    <snip>

    I'm guessing that the problem is that you do not have a prototype in
    scope and you need one. When splitting a project in to multiple files it
    is normal to do something like:

    /* foo.h */
    #ifndef H_FOO
    #define H_FOO

    unsigned long foo(unsigned long x);

    #endif

    /* foo.c */
    #include "foo.h"

    unsigned long foo(unsigned long x)
    {
    return x * 3;
    }

    /* main.c */
    #include "foo.h"
    ....

    This way the compiler always knows the correct types of everything.
    Otherwise it is required to make assumptions that are not always true.

    > ------
    > 4. stdarg.h
    > For some reason, I can use vsprintf, but not vprintf, so I did this:
    >
    > int __CDECL vprintf (const char *format, va_list arg) {
    > char prt[200+1];
    > vsprintf(prt, format, arg);
    > return puts(prt);
    > }
    >
    > Keep in mind malloc is not an option. That works, but I wonder what
    > would be a better way to write it.


    Why can you not use vprintf? My first guess would be that you were using
    it incorrectly, and solving that problem would be better than working
    around it.

    > I really thought that something similar to the following
    > implementation of dprintf and rdprintf was quite logical to deduce,
    > but it never hurts to give my practical example:
    >
    > int dprintf (int mode, const char* fmt, ...) {
    > va_list arglist;
    > int result;
    > int oldmode;
    > if (mode >= 0) {
    > oldmode = GetVideoMode();
    > SetVideoMode(mode);
    > }
    > va_start(arglist, fmt);
    > result = vprintf(fmt, arglist);
    > va_end(arglist);
    > if (mode >= 0) SetVideoMode(oldmode);
    > return result;
    > }


    <snip>

    Nothing looks wrong in the above, assuming your use of non-standard
    functions is correct and you have included the correct headers for all
    of the functions.

    > The "mode" could be anything else and, in fact, I have many more
    > parameters in dprintf.


    <snip>

    Here is a major problem. If you do not provide a small complete example
    that actually shows the problem we don't stand much chance of diagnosing
    it. Consider that if you do not know what is causing the problem then
    you do not know it is in part of the code you are not showing. You may
    also find that in cutting the program down to a failing example small
    enough to post you actually find the problem.

    This advice applies to any group you are posting to, including
    comp.arch.embedded which I *think* might be an appropriate group.
    --
    Flash Gordon
     
    Flash Gordon, May 16, 2007
    #6
  7. Cawas <> writes:
    > Thanks for your prompt reply, Flash! I really was not counting with
    > such attention in any answer.


    When posting a followup, you should usually quote the relevant parts
    of the parent article. See most of the articles here for examples.
    See also <http://cfaj.freeshell.org/google/>. In this particular
    case, your followup is probably clear enough without quoted context,
    but keep it in mind for future postings.

    > If it were not for being such a peculiar issue I would be having no
    > problems finding answers in the groups. I'm really not much a fan of
    > posting repeated subjects. I see what you mean about lots of my
    > questions being non-topics in here, but if I want to use google groups
    > for this topic, what should I do? Create a new group under
    > comp.lang.c ? I was hoping here would be a good place to ask for
    > directions and instead of being vague by stopping at the first
    > paragraphs, I've wanted to give specific details about it.


    You need to be aware that Google Groups is *not* Usenet. Usenet is a
    distributed discussion forum that has existed for several decades.
    Google Groups is, among other things, an archive of Usenet and a
    (sometimes rather inconvenient) interface to it. comp.lang.c is a
    Usenet newsgroup; Google Groups does not own it.

    In general, the trick is to find a forum where your questions are
    topical. There may be a Usenet newsgroup that fits your needs. If
    not, Google Groups may have some non-Usenet group.

    [...]

    > Well,
    > The "simple" library without malloc is needed because I was told
    > malloc is not well implemented on this terminal, and should not be
    > used. I was actually using malloc in my program before, without any
    > problems, but I removed all of them under that advice, and I'd like to
    > keep it safe and go without it because I'm not sure why malloc could
    > be such an issue for the terminal. But even using just static memory
    > the regular C "string" is a pain, to mention the less.


    I don't know what you mean by "terminal". Are you working with some
    kind of embedded system?

    If you need dynamically allocated storage that's can be deallocated
    before the program terminates, and that doesn't vanish at the end of
    the scope in which it's created, then malloc() and friends are the
    only tool the C language offers. If your implementations's malloc()
    is somehow broken, you may be able to roll your own. For example, you
    might declare a sufficiently large static array, and provide your own
    functions to allocate chunks from it. I think K&R2 has a sample
    memory allocator; it might be instructive.

    If you don't need the full generality of malloc, realloc, and free,
    that might make rolling your own a bit simpler. For example, if all
    your allocations are the same size, you don't need to worry about
    fragmentation. If your allocated chunks of memory are always going to
    be deallocated in the reverse of the order in which they were
    allocated, you can use a stack-like scheme. And so on.

    [snip]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 16, 2007
    #7
  8. Cawas

    Cawas Guest

    On May 16, 4:25 pm, Keith Thompson <> wrote:
    > When posting a followup, you should usually quote the relevant parts
    > of the parent article. See most of the articles here for examples.
    > See also <http://cfaj.freeshell.org/google/>. In this particular
    > case, your followup is probably clear enough without quoted context,
    > but keep it in mind for future postings.


    Cool, but that far I knew from my forums experience, I did not quote
    in purpose. ;-)


    > You need to be aware that Google Groups is *not* Usenet. Usenet is a
    > distributed discussion forum that has existed for several decades.
    > Google Groups is, among other things, an archive of Usenet and a
    > (sometimes rather inconvenient) interface to it. comp.lang.c is a
    > Usenet newsgroup; Google Groups does not own it.
    >
    > In general, the trick is to find a forum where your questions are
    > topical. There may be a Usenet newsgroup that fits your needs. If
    > not, Google Groups may have some non-Usenet group.
    >


    Hmm, I did read the overview ( http://groups.google.com/intl/en/googlegroups/overview.html
    ) and the tour. I just did it again now, and I could not find where it
    says something about being an interface to usenet, but I do remember I
    read somewhere that it had archives from usenet (maybe it was
    wikipedia) but I was led to believe usenet didn't exist anymore, or at
    least that google groups was not linked to it, just had archives.

    For one, I was really thinking of it as forums, rather than
    newsgroups. I never liked newgroups due to the "spam nature" of it.
    Back when Netscape Navigator were popular, and we could choose to
    receive e-mails and newsgroups... That was awfull! Oh well, maybe this
    is still the closest to the major forum that I was hoping to exist by
    today. I've tried to find regular forums in the past, but I still
    couldn't find a place that feels like home. I'm still hoping it could
    be google groups + usenet, however it should be called.

    > I don't know what you mean by "terminal". Are you working with some
    > kind of embedded system?


    That's it. Embedded system. Sorry about that. *adding new word to
    vocabulary*. :p

    But I still think that at least the vprintf thing belongs here.


    > If you need dynamically allocated storage that's can be deallocated
    > before the program terminates, [...]
    >


    Yeah, I don't quite need, and *I hope* I've never said that I did,
    dynamically allocated storage. But I never thought about building my
    own malloc, that could be intersting. This system is, after all,
    limited. It has very little memory. One of them have just 200kb RAM,
    and that's for storage. Being able to use malloc could be nice or even
    needed eventually, but it could also lead to more problems in the
    later case. I'll certainlly look for that later on, but that was not
    the only problem I had with implementing bstring.

    Now... I just wonder if I should add my next reply in here, or make a
    new one as this GG interface suggessts.
     
    Cawas, May 17, 2007
    #8
  9. Cawas said:

    <snip>

    > Hmm, I did read the overview (
    > http://groups.google.com/intl/en/googlegroups/overview.html ) and the
    > tour. I just did it again now, and I could not find where it says
    > something about being an interface to usenet, but I do remember I read
    > somewhere that it had archives from usenet (maybe it was wikipedia)
    > but I was led to believe usenet didn't exist anymore,


    You were led to believe wrong. If Google ceased to exist *right now*,
    the only effect on comp.lang.c would be that the signal-to-noise ratio
    would increase slightly.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, May 17, 2007
    #9
  10. Cawas

    Default User Guest

    Cawas wrote:


    > Hmm, I did read the overview (
    > http://groups.google.com/intl/en/googlegroups/overview.html ) and the
    > tour. I just did it again now, and I could not find where it says
    > something about being an interface to usenet, but I do remember I
    > read somewhere that it had archives from usenet (maybe it was
    > wikipedia) but I was led to believe usenet didn't exist anymore, or
    > at least that google groups was not linked to it, just had archives.


    You didn't read the right stuff.

    <http://groups.google.com/support/bin/answer.py?answer=46854&topic=9246>





    Brian
     
    Default User, May 17, 2007
    #10
  11. Cawas

    Guest

    On May 15, 1:12 pm, Cawas <> wrote:
    > Cipher Lab produces some terminals to collect data where we can
    > program using one implementation of plain C which I believe to be ANSI
    > C89 compatible, although not fully. They have their on set of
    > libraries as well, but all in all, it's basic C we're talking about.
    >
    > [...] Particularly, I'd love to know if someone could sucessfully use
    > any well known string library on it, such as Paul Hsieh's bstring
    > (http://bstring.sourceforge.net), although I doubt it. And I know for
    > experience that it would be nice to share some custom made libraries
    > to solve lots of troubles on those terminals, since I've been
    > painfully building one myself, from scratch.


    Why do you doubt it? The Better String Library needs about 20K or so
    of code space. Other than that it optionally uses the vsnprintf()
    function (which some compilers don't support) but that's all explained
    in the porting guide. As long as your compiler is fairly close to
    ANSI C 89, there should be no problem. The Better String Library is
    *very* portable to most ANSI (or near-ANSI) C compilers.

    IBM held a kind of "massive porting effort" of a bunch of libraries on
    source forge to their Linux on Power systems. The Better String
    Library had a "non-issue" warning in the examples that was fixed with,
    an 8 character change -- otherwise it worked perfectly.

    > The next "topics" I'll try to bring are:
    > 1. strings - I think 90% of all troubles I'm having are from trying to
    > manipulate them. A good simple workaround library, which does not use
    > malloc, would be greatly appreciated. But maybe I'll just finish my
    > own soon enough.


    The Better String Library uses malloc. You might like to look at
    firestring as a library that has a non-malloc sub-library for strings.

    > 4. stdarg.h - it does not have va_copy, but I'm not having an issue
    > with that. Although I'd love to see an implementation of va_copy since
    > I have no idea how to write it, my problem here is on using it to
    > create my own vprintf. I could create a "dprintf" that works just
    > fine, but I've wanted to expand it, making a rdprintf that would use
    > dprintf. For that, I need to create a vdprintf, and that's where I
    > can't go beyond.


    You should look through the Better String Library's bvformata() macro
    for insight into how this was accomplished in a C89 portable way.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , May 19, 2007
    #11
  12. Cawas

    Cawas Guest

    For some reason, Ggroups ate my answer to this.... Let me do it again,
    and renewed. :p

    On May 16, 4:19 pm, Flash Gordon <> wrote:
    > Cawas wrote, On 16/05/07 16:03:
    >
    > > Thanks for your prompt reply, Flash! I really was not counting with
    > > such attention in any answer.

    >
    > > If it were not for being such a peculiar issue I would be having no
    > > problems finding answers in the groups. I'm really not much a fan of
    > > posting repeated subjects. I see what you mean about lots of my
    > > questions being non-topics in here,

    >
    > Making a mistake is fine.
    >
    > > but if I want to use google groups

    >
    > > for this topic, what should I do?

    >
    > Firstly, this is not Google Groups. Google Groups is merely one
    > interface on to a far larger thing called Usenet, something that existed
    > before Google existed.
    >
    > > Create a new group under

    >
    > > comp.lang.c ?

    >
    > No. There is a procedure for creating groups, a procedure that has
    > nothing to do with Google, and I doubt that you would succeed.
    >
    > I suggest you look for mailing lists dedicated to your system.
    >
    > Also, if your system is an embedded system then comp.arch.embedded may
    > be able to offer some assistance.
    >
    > <snip>


    That's really good to know. But creating a group in ggroups seems
    fairly easy, maybe I'll try this later on, when I have something (or
    at least some people) to start it with.

    >
    > > Well,
    > > The "simple" library without malloc is needed because I was told
    > > malloc is not well implemented on this terminal, and should not be
    > > used. I was actually using malloc in my program before, without any
    > > problems, but I removed all of them under that advice, and I'd like to
    > > keep it safe and go without it because I'm not sure why malloc could
    > > be such an issue for the terminal. But even using just static memory
    > > the regular C "string" is a pain, to mention the less.

    >
    > First rule of optimisation, don't do it. If the performance of your
    > application was fine with malloc and that was the clearest way to write
    > it you should have stuck with it. Something I've learnt is that many of
    > the "don't do this because it is inefficient" suggestions are no longer
    > relevant because technology has moved on. Also, it is easier to speed up
    > a working and clearly written program than to get a fast but hard to
    > read program working correctly.


    I agree with you, but I didn't see it as optimization, I was thinking
    in preventing bugs. I don't know why they told me to keep away from
    malloc, and I know questioning it could be troublesome. Maybe there's
    nothing wrong with this malloc implementation, but now I've changed
    everything to work without it anyway. That wasn't a problem.

    And it wasn't the clearest way, but I started with it because I hate
    static things. I'd use as many variables as possible. Still, making
    things dynamic (with malloc) in C is way more confusing than keeping
    it static.

    >
    > > As for Paul, I would not bother him with this. He seems to enjoy

    >
    > <snip>
    >
    > You might be surprised. He has certainly been prepared to halp on far
    > simpler things.


    I'm already surprised now. :p
    Evenmore cuz it seems he uses ggroups, or at least a gmail.


    > > I'm still trying to reproduce the actual problem I'm having, but
    > > meanwhile I'll just describe it here. The following code works fine,
    > > if compiled with syntech's CC900.EXE which comes with the terminal,
    > > for the model CPT8100:

    >
    > > In case you wonder, the 8100lib.h implements printf, and maybe all of
    > > stdio.h (I haven't checked it).

    >
    > From the sounds of this comp.arch.embedded may well be a better place
    > for initial questioning.
    >


    So far no good. Maybe I'll try to shake my post there a little bit.
    Plus, I've stoped trying to fix this for now, but I think it belongs
    here anyway. It is, most likely, something wrong in some obscure part
    of my code, of course, but it seems to me it's something related to
    variable types.


    >
    >
    > > #include <ucos.h>
    > > #include <8100lib.h>

    >
    > > #define DELAY 5000 /* ms */

    >
    > > unsigned long sysmsec (void) { return sys_msec * 5; }

    >
    > > void foo (const unsigned long delay) {
    > > const unsigned long final_msec = sysmsec() + delay;
    > > while (sysmsec() < final_msec) {
    > > gotoxy(0, 7);
    > > printf("%ld,%ld", sysmsec()+delay, sysmsec());
    > > }
    > > }

    >
    > > void bar (void) {
    > > foo(DELAY);
    > > }

    >
    > > int main (void) {
    > > gotoxy(0, 0);
    > > printf("%ld", sysmsec());
    > > bar();

    >
    > > gotoxy(0, 1);
    > > printf("%ld", sysmsec());
    > > foo(DELAY);

    >
    > > return 0;
    > > }

    >
    > > In practice, I have just "main" in a separated file (although I'm just
    > > using include to concatanate all separated files, instead of compiling
    > > them separatedly), and if I try to call the equivalent of foo(DELAY)
    > > the delay inside foo comes with a random gigantic value, while the
    > > equivalent of bar(), which has also just that one line, works just
    > > fine.

    >
    > <snip>
    >
    > I'm guessing that the problem is that you do not have a prototype in
    > scope and you need one. When splitting a project in to multiple files it
    > is normal to do something like:
    >
    > /* foo.h */
    > #ifndef H_FOO
    > #define H_FOO
    >
    > unsigned long foo(unsigned long x);
    >
    > #endif
    >
    > /* foo.c */
    > #include "foo.h"
    >
    > unsigned long foo(unsigned long x)
    > {
    > return x * 3;
    >
    > }
    >
    > /* main.c */
    > #include "foo.h"
    > ...
    >
    > This way the compiler always knows the correct types of everything.
    > Otherwise it is required to make assumptions that are not always true.
    >


    I wonder what assumptions. And that's a good guess, but wouldn't that
    bring troubles to calling the function altogether, rather than
    troubles with just one parameter? I mean, my actual function do have
    more parameters, and that one I'm using in foo is just its last one.
    Plus, as I said, there's just 1 scope. Unless the pre-compiler does
    not include files as I assumed from the name that it would.

    I've made few more tests with it, and foo() also works fine if I call
    it from main. It does not work just from inside a few functions I've
    tried. One of them looks like this:

    int write_read (int nPort, const char header[], const char term[]) {
    char buff[200+1];
    char stxt[120+1], saux[120+1], crc[2+1];
    int result, i, t = 0;

    foo(DELAY);
    /* code of function goes here */

    return result;
    }

    As soon as the function starts, if I try to call not foo, but the
    similar function, it already brings a big number (last time was
    1940851640), but if I call bar, everything works fine. I don't know
    how this could be related to the function, but the fact is if I try
    calling my "foo_alike" function from some places, it works, and from
    other places, it does not (keeping in mind "bar_alike" works always).

    Also, I'm printing just ("%d,%d", delay, final_msec) now, so the
    1940851640 comes directly from delay.

    I may be drawing the wrong picture, but that's what seems weird to me:

    - a function calls foo(5000)
    - foo prints 1940851640
    - the same function calls bar() in the very next line (or previous)
    - bar calls foo(5000)
    - foo prints 5000

    Anyway, don't worry too much about this, it seems it's something un-
    guessable. I just thought there was a chance that I might be doing
    something really wrong and the symptoms would reveal it easily, so I
    just tried to describe the symptom.

    And I did get around it with using the bar(), although it is an
    intriguing fix.


    > > ------
    > > 4. stdarg.h
    > > For some reason, I can use vsprintf, but not vprintf, so I did this:

    >
    > > int __CDECL vprintf (const char *format, va_list arg) {
    > > char prt[200+1];
    > > vsprintf(prt, format, arg);
    > > return puts(prt);
    > > }

    >
    > > Keep in mind malloc is not an option. That works, but I wonder what
    > > would be a better way to write it.

    >
    > Why can you not use vprintf? My first guess would be that you were using
    > it incorrectly, and solving that problem would be better than working
    > around it.
    >


    If I try to use vprintf the linker brings me this error:
    TULINK-Error-209: Reference made to unresolved external symbol
    "_vprintf"

    I've checked, it's actually on the header file, but probably not in
    the library, for any reason. Plus, vsprintf do work.

    >
    >
    > > I really thought that something similar to the following
    > > implementation of dprintf and rdprintf was quite logical to deduce,
    > > but it never hurts to give my practical example:

    >
    > > int dprintf (int mode, const char* fmt, ...) {
    > > va_list arglist;
    > > int result;
    > > int oldmode;
    > > if (mode >= 0) {
    > > oldmode = GetVideoMode();
    > > SetVideoMode(mode);
    > > }
    > > va_start(arglist, fmt);
    > > result = vprintf(fmt, arglist);
    > > va_end(arglist);
    > > if (mode >= 0) SetVideoMode(oldmode);
    > > return result;
    > > }

    >
    > <snip>
    >
    > Nothing looks wrong in the above, assuming your use of non-standard
    > functions is correct and you have included the correct headers for all
    > of the functions.


    You can assume that. :)
    It does not matter, if you get the point of what I want. But...

    >
    > > The "mode" could be anything else and, in fact, I have many more
    > > parameters in dprintf.

    >
    > <snip>
    >
    > Here is a major problem. If you do not provide a small complete example
    > that actually shows the problem we don't stand much chance of diagnosing
    > it. Consider that if you do not know what is causing the problem then
    > you do not know it is in part of the code you are not showing. You may
    > also find that in cutting the program down to a failing example small
    > enough to post you actually find the problem.
    >
    > This advice applies to any group you are posting to, including
    > comp.arch.embedded which I *think* might be an appropriate group.
    > --
    > Flash Gordon


    .... It seems you didn't get my point here. I'm not having a problem at
    this point (4). I just want to write an implementation similar to what
    vprintf is to printf. So, just seeing those implemented would be
    enough to me, but I couldn't find them. In fact, just vprintf must be
    enough, but since I'm not sure how this works, I'd go for printf as
    well.

    I'm still trying to follow Paul's advice on bvformata() tho... But I
    still couldn't find it... *back to replying to Paul*
     
    Cawas, May 24, 2007
    #12
  13. Cawas

    Cawas Guest

    It seems like Ggroups failed to deliver my last reply, once again...
    Maybe I can't post one few minutes after the other. The really bad
    side is that I've lost what I've written then.

    On May 19, 3:36 am, wrote:
    > On May 15, 1:12 pm, Cawas <> wrote:
    >
    > > Cipher Lab produces some terminals to collect data where we can
    > > program using one implementation of plain C which I believe to be ANSI
    > > C89 compatible, although not fully. They have their own set of
    > > libraries as well, but all in all, it's basic C we're talking about.

    >
    > > [...] Particularly, I'd love to know if someone could sucessfully use
    > > any well known string library on it, such as Paul Hsieh's bstring
    > > (http://bstring.sourceforge.net), although I doubt it. And I know for
    > > experience that it would be nice to share some custom made libraries
    > > to solve lots of troubles on those terminals, since I've been
    > > painfully building one myself, from scratch.

    >
    > Why do you doubt it? The Better String Library needs about 20K or so
    > of code space. Other than that it optionally uses the vsnprintf()
    > function (which some compilers don't support) but that's all explained
    > in the porting guide. As long as your compiler is fairly close to
    > ANSI C 89, there should be no problem. The Better String Library is
    > *very* portable to most ANSI (or near-ANSI) C compilers.
    >
    > IBM held a kind of "massive porting effort" of a bunch of libraries on
    > source forge to their Linux on Power systems. The Better String
    > Library had a "non-issue" warning in the examples that was fixed with,
    > an 8 character change -- otherwise it worked perfectly.


    For a number of reasons. One of them is the "not fully" compatible.
    I'm not sure what is missing, I haven't compared the headers with the
    ANSI C89 standard, if that would be enough to know it. But there is
    that malloc issue and vprintf seems to not be in this library. Don't
    get me wrong, I'd love to point things to fix in bstring, but I'm not
    that expert just yet. I'm blaming this system I'm using for not being
    able to take bstring, not the other way around.

    stdio.h, for example, does not have snprintf at all, and it does have
    vprintf (which does not work when linking, as mentioned in my previous
    post). There are lots of lines commented out, saying "not support",
    but those are mostly ok, since they deal with files, and the embedded
    system has its own file system.

    >
    > > The next "topics" I'll try to bring are:
    > > 1. strings - I think 90% of all troubles I'm having are from trying to
    > > manipulate them. A good simple workaround library, which does not use
    > > malloc, would be greatly appreciated. But maybe I'll just finish my
    > > own soon enough.

    >
    > The Better String Library uses malloc. You might like to look at
    > firestring as a library that has a non-malloc sub-library for strings.
    >


    Hmm... sub-library, huh? That might work, I'll sure try it.


    > > 4. stdarg.h - it does not have va_copy, but I'm not having an issue
    > > with that. Although I'd love to see an implementation of va_copy since
    > > I have no idea how to write it, my problem here is on using it to
    > > create my own vprintf. I could create a "dprintf" that works just
    > > fine, but I've wanted to expand it, making a rdprintf that would use
    > > dprintf. For that, I need to create a vdprintf, and that's where I
    > > can't go beyond.

    >
    > You should look through the Better String Library's bvformata() macro
    > for insight into how this was accomplished in a C89 portable way.
    >
    > --
    > Paul Hsieh


    Yeah, sure. I'm already using bstring as a reference for lot of
    things, even if I can't use it directly. It's always good to see a
    working and well commented library. I did look for something like this
    in it before, but I couldn't find it. I had the 01232007 one, I guess
    it wasn't there yet. So I've downloaded the new one, 03312007, and
    there it was! :)

    But it still doesn't help me much.

    Basically, I can easily find anywhere how to make a function(...) to
    call a function(va_list), and in bstring now I could see a
    function(va_list) calling another function(va_list), which now I know
    doesn't need to use va_start, and that was bvcformata calling
    vsnprintf via macro. But I want to make a function(...) to call
    another function(...) and since vprintf exists, I figured that it is
    not possible. So I figured I'd need to build a function(va_list) to
    call the function(...) so the cycle can be closed.

    I didn't thought at first it would be this hard to find some code
    showing that.
     
    Cawas, May 25, 2007
    #13
  14. Cawas

    CBFalconer Guest

    Cawas wrote:
    >
    > It seems like Ggroups failed to deliver my last reply, once again...
    > Maybe I can't post one few minutes after the other. The really bad
    > side is that I've lost what I've written then.


    It is high time you installed a real newsreader and accessed a real
    news server. In addition, this is off-topic for c.l.c.

    Please do not top-post. Your answer belongs after (or intermixed
    with) the quoted material to which you reply, after snipping all
    irrelevant material. See the following links:

    --
    <http://www.catb.org/~esr/faqs/smart-questions.html>
    <http://www.caliburn.nl/topposting.html>
    <http://www.netmeister.org/news/learn2quote.html>
    <http://cfaj.freeshell.org/google/> (taming google)
    <http://members.fortunecity.com/nnqweb/> (newusers)



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, May 25, 2007
    #14
  15. On 25 May 2007 08:10:07 -0700, Cawas <> wrote:
    <snip much>
    > Basically, I can easily find anywhere how to make a function(...) to
    > call a function(va_list), and in bstring now I could see a
    > function(va_list) calling another function(va_list), which now I know
    > doesn't need to use va_start, and that was bvcformata calling
    > vsnprintf via macro. But I want to make a function(...) to call
    > another function(...) and since vprintf exists, I figured that it is
    > not possible. So I figured I'd need to build a function(va_list) to
    > call the function(...) so the cycle can be closed.
    >

    Right, it's not possible standardly and portably to construct a call
    with variable arguments. You can have multiple calls (sites), each
    with different argument types, to one (x, ...) routine, assuming that
    routine is able to handle those types, but each call has a fixed list
    of types. The closest you can come is something like:
    void (*f_v) (int,...) = somevarargfunction;
    int (*f_i) (int,...) = (int(*)(int,...) f_v;
    ...
    int int_ret, int_1; double real_2; char * str_3 = malloc (x);
    switch( encoded_arg_types ){
    /* if you can represent your cases in an int value;
    if you need a string or struct or something, do
    a series of if(strcmp( )) ... else or similar instead */
    case VOID_ARGS_INT_STR: (void) (*f_v) (int_1, str_3); break;
    case INT_ARGS_INT_REAL: int_ret = (*f_i) (int_1, real_2); break;
    ...
    }
    (Aside: You don't actually need the explicit deref (*fptr) (args),
    just fptr (args) will work, but I show it for emphasis.)

    > I didn't thought at first it would be this hard to find some code
    > showing that.


    This is precisely why the approach commonly recommended, including the
    FAQ, and used, is to have a 'real/core' routine that takes a va_list,
    which can then be called from a vararg wrapper(s) or through any
    number of levels of va_list routines, as long as in portable C89 you
    only go through each 'original' list once, and with va_copy in C99 (or
    as an extension) you don't even have that limitation.

    - formerly david.thompson1 || achar(64) || worldnet.att.net
     
    David Thompson, Jul 1, 2007
    #15
    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. Gary

    Cipher.unwrap

    Gary, Aug 8, 2003, in forum: Java
    Replies:
    0
    Views:
    1,234
  2. Andrew Thompson

    StringTokenizer Lab

    Andrew Thompson, May 23, 2004, in forum: Java
    Replies:
    14
    Views:
    750
    Dale King
    Apr 15, 2006
  3. Replies:
    0
    Views:
    361
  4. dbee
    Replies:
    0
    Views:
    587
  5. marksauder

    Need help with LAB assignment

    marksauder, Nov 16, 2008, in forum: VHDL
    Replies:
    0
    Views:
    624
    marksauder
    Nov 16, 2008
Loading...

Share This Page