[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[f-cpu] [Fwd: [whygee@f-cpu.org: Re: vanilla vs simili]]
- To: fm <f-cpu@seul.org>
- Subject: [f-cpu] [Fwd: [whygee@f-cpu.org: Re: vanilla vs simili]]
- From: Yann Guidon <whygee@f-cpu.org>
- Date: Sun, 16 Sep 2001 00:42:53 +0200
- Delivered-To: f-cpu@seul.org
- Delivery-Date: Sat, 15 Sep 2001 18:43:16 -0400
- Organization: http://www.f-cpu.org
- Reply-To: f-cpu@seul.org
- Sender: owner-f-cpu@seul.org
hello,
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
hello,
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 :-)
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- 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/