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

[f-cpu] [Fwd: [whygee@f-cpu.org: Re: vanilla vs simili]]


it seems that these mails did not go to the list.
sorry for the delay.

----- Forwarded message from Yann Guidon <whygee@f-cpu.org> -----

From: Yann Guidon <whygee@f-cpu.org>
To: Haneef Mohammed <haneef@symphonyeda.com>
Cc: f-cpu@seul.org
Subject: Re: vanilla vs simili


Haneef Mohammed wrote:
> > simili. Maybe it was fixed long ago. But stopping on a 0xFF
> > is not a good sign for a C program. I know : Simili is written
> > in C++ and i don't know a damn about it. So i will let
> Dont worry about what other *experts* say. Simili does *NOT*
> stop at 0xFF or at ^Z. The problem you say in the older version of the
> Simili has to do with opening the file in text-mode (an OS
> function) which does all kinds of translations like ^Z is EOF,
> \r\n becomes \n, etc. and nothing to do with C/C++. Note that
> Unix/Linux has no distinction between binary/text modes....all
> files are binary....whereas in DOS the default mode is text.
> If you use the latest Simili, you will see no problems with
> reading binrary files (you may still have a problem writing
> a binrary file with respect to \n (will be written as \r\n).

i understand that well, and i just started to test 15b17.
I apologize for my laziness to update my files.
to my defense, all i brought to London was a set of old backup CDs
with an old installed Simili. From experience, i saw that trying
to install Simili from the original package was difficult so i couldn't
update the files in London. And as you noted, file I/O is pretty ...
undetermined in VHDL. I know i am pushing the enveloppe very far :-)

> Before I implemented binary files, I asked around about
> the std. formats for binary output. Turns out that there is none.
> So, binary files are all done differently by each of the
> simulators and there is no compatibility standard. There is
> not even a little-endian/big-endian requirement. So, doing
> binary I/O on anything other than bytes (characters) will
> not be portable.
i know. In the case there is no capability for decent I/O, the
F-CPU package provides a 'failsafe' file that does ... nothing.
I am conscious of the limitations concerning the files and
you just confirmed what i feared (i believe you _are_ an "expert" :-D)

> Here is what simili does...
> 1. Enumerated types with <= 256 literals - 1 byte
> 2. Other enumerated literals - 4 bytes (treated as integers)
> 3. Integers (regardless of range) - 4 bytes and it goes (byte0 byte1 byte2 byte3)...
>         where byte0 is lsB and the 4 bytes concatenated in reverse order
>         will recreate the 32-bit integer
> 4. Reals - 8 bytes (this is machine dependent)
> 5. Physical types -- 8 bytes (High Integer, low integer)
> 6. Arrays -- size, 'left item .... 'right item
> 7. Records -- quite complicated :-)

it seems to follow quite "obvious" rules.
hmmm... what about the "character" mode ? from the previous paragraphs
i guess it is an "enumerated" with "256 literals".

> Also, the format above is subject to change (if I go to
> 64-bit or for some other reason). You can however rely on rule#1
> above for the most part.....

i wish i will _never_ have to rely on them. "binary" byte input is enough.
Thank you for your precision anyway.

> Regards,
> Haneef
> PS: Suggestion: If you just want random numbers why not use an LFSR.
> It works quite well, is portable, small, fast, etc.

I thought about that, too, some time ago :-)


----- End forwarded message -----
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/