[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/