On Tue, Jul 19, 2011 at 04:21, Michael Vacek wrote:
>> get the feedback below sorted out and i think i can live with the rest
>> (for now) to merge it
>
> After you merge it, I will post some hints where to start with the
> implementation of 64-bit stapl patch to give a clue to others. It could
> be quite a nice programming exercise :o). Thank you for providing of
> detailed guide how the code should be modified, it saved me a lot of time
> and further iterations. See the feedback below.
just add the tips to the TODO file
>> > in general: "return (foo);" should be "return foo;"
>>
>> seems like this is still valid. many can probably be fixed with a sed
>> like:
>> sed -i '/return/s:(^[[:space:]]*return )[(](.*)[)];$:\1\2;:' *.c
>
> Done, however, the above sed expression does not work for me. There is
> probably typing error.
probably ... i didnt actually test it, just banged it out in the
e-mail ;) ... testing ... oh, you need to use the -r flag to sed as
well, then it works
>> > typedef int BOOL;
>>
>> drop these and use stdbool.h and "bool". maybe this sed will help:
>> sed -i 's:\<BOOL\>:bool:g' *.[ch]
>
> I forgot to mention it in the last reply. The code supposes that this
> bool-like type is 4 bytes long instead of 1 byte in case of "bool". So,
> I left there the "int" type for now.
ok ... we'll want to note this in the TODO and add a comment right
above the typedef
>> > +/* # line 288 "jamexp.y" */
>>
>> i dont suppose you have jamexp.y instead ? we would want to keep that
>> in svn, not the generated jamexp.c ...
>
> No, we have not. I am not acquainted with this bison/lex technology, is
> there any way to perform a reverse generation?
unfortunately, not easily :(. and it'd require familiarity with what
source yacc looks like when turned into compiled C ... i'm not that
familiar to pull it off.
i guess just add a comment block to the top of the file like:
* Upstream Altera code dump only included the generated C code
* and not the source yacc, so we're stuck with this file for now.
>> > src/stapl/jamheap.c
>> > +jam_init_heap (void)
>> > +jam_free_heap (void)
>>
>> is there a reason you need this at all ? why cant it simply call
>> malloc() and free() like sane code ?
>
> The reason is very likely historical, since the software was portable to a
> whole variety of embedded systems where malloc() and free() could not be
> used.
> In general, these functions should be located in operating system stub
> instead of the program itself even in the case of embedded systems. After
> 64-bit
> system issue will be solved, it could be probably changed.
ok, just add to the TODO for now:
- kill off local heap management and replace with malloc()/free()
> urjtag/doc/README.stapl:
> +UrJTAG must be configured with disabling of -Werror; thus, "autogen.sh
> +--enable-stapl --disable-werror".
is this still true ? if so, we can tweak the stapl Makefile to take
care of this for us:
AM_CFLAGS = $(WARNINGCFLAGS) -Wno-error
> +static const char *error_text[] = {
> +static const char *exit_text_v2[] = {
> +static const char *exit_text_vd[] = {
pretty sure these all should be "static const char * const foo[] = {"
-mike
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development
