[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] snapshot QDCPOC+YGASM



hi !

Andreas Romeyke wrote:
> Hello,
> 
> > i think that i had left some compiler errors in the code, AFAIK nothing really harmful,
> > unless you get something really annoying such as SIGSEGV or or something like that.
> In qdcpoc/control.c are some errors:
> 
> line 342: `loadcons_shift' undeclared (first use in this function)
> line 367: there is a constant missing between "~" and ")"

i had fixed that locally, after the file was sent. sorry.

> Your programm "ygasm" generates segfault without paramters:
this surprises me ...
OTOH, i only tested it with the 1 or 2 arg. format.

> Program received signal SIGSEGV, Segmentation fault.
> 0x4006f3de in vfprintf () from /lib/libc.so.6
> (gdb) bt
> #0  0x4006f3de in vfprintf () from /lib/libc.so.6
> #1  0x4007229b in vfprintf () from /lib/libc.so.6
> #2  0x4006da9f in vfprintf () from /lib/libc.so.6
> #3  0x400767d5 in fprintf () from /lib/libc.so.6
> #4  0x8048940 in ygasm_warning (
>     msg=0x804f0e0 "sending binary stream to the console", ptr=0x0)
>     at ygasm_errors.c:24
> #5  0x804b083 in init_flex (argc=0, argv=0xbffffce8) at ygasm.l:452
> #6  0x804bffb in main (argc=1, argv=0xbffffce4) at ygasm.c:65
> #7  0x4003d38b in __libc_start_main () from /lib/libc.so.6
> 
> The reason can be found at line 435 in file ygasm.l (if you have none
> args, your pointers are wild and crazy, is not it?)

that's weird ! the skeleton of this source was written more than 3 years ago...
i'll check that, thanks !

<checking on the laptop>

oh yeah... i'm such a bad C programmer !


> Hello,
> On Thu, 2 Aug 2001, Yann Guidon wrote:
> > > > ie : loadcons uses 4 bits that overlap the opcode.
> > > Huh?  That should not be a problem at all in C.
> > it's not a problem with C. I realized that with the current syntax,
> > i would have to bit-reverse every field to make then senseful.
> > for example, when the opcode is encoded/decoded in the least significant
> > byte, i found that the LSB of the opcode (see the #defines) became the MSB
> > of the byte. something was clearly wrong.
> But that's only a problem in building a compiler or assembler, not in
> coding assembler for f-cpu, is not it?
this is at the binary level (in the executable generated file),
not the user or syntax level. however, it's annoying for me anyway :-)

> > people are/were not used to having the opcode at the last position,
> > hence the bit-reversing. if we re-reverse the bits, we have to
> > change the endianness too, which is not a huge problem in itself,
> > after all.
> I think we could not detect all places in documentation for changing.
the documentation is horribly lagging. i am too much behind it to catch up
and IIRC it's someone else's work to update the manual.

> The better way IMHO is to write a better assembler instead...
> Or I missunderstood the problem?
the assembler and simulator have been updated to reflect the bit reversal,
it took one hour (twoif i count a few tetris games inbetween).

> Bye Andreas
> 
> PS.: Can we use qdcpoc to testing GCC-stuff? Or were it successfully
> tested?
as you have remarked, nothing is fully tested.
i refuse to spread something of this bad quality.
This is written in the readme's.
it is interesting for people who want to have a rough idea of
how i use FLEX+BISON to assemble F-CPU code. the syntax is
not definitive, i think that several people have done each one's
own version of the assembler and the syntax. We will have
to define a standard syntax to make everything compatible.

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/