Path: news.cs.au.dk!news.net.uni-c.dk!uninett.no!news.maxwell.syr.edu!sunqbc.risq.qc.ca!news.uunet.ca!not-for-mail From: Karl Waclawek Newsgroups: comp.lang.beta Subject: Re: How to do low level stuff Date: Fri, 08 Jan 1999 10:56:02 -0500 Organization: The Toronto Star Lines: 65 Message-ID: <36962A92.3E082DDA@thestar.ca> References: <368B8A70.CF9934FF@thestar.ca> <36950D20.2FAD4D18@thestar.ca> NNTP-Posting-Host: 192.206.151.130 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Xref: news.cs.au.dk comp.lang.beta:11776 Morten Grouleff wrote: > > Karl Waclawek writes: > > [...] > > > I thought BETA did not make specific assumptions about the size and > > the byte ordering of the basic types. From what your code shows, > > however, it seems that one can assume that Char is stored in one Byte > > and that Integer is stored in 4 Bytes. My Pascal code really relies on > > the fact that a LongWord consists of 4 bytes ordered in a specific > > way. As far as your code goes, I think the semantics are right, but it > > relies on the byte ordering too (as well as bit shifting semantics). > > I also think that the CRC algorithm dependens on the byte ordering, > > but I don't know for sure. > > No, not really. You can read the shift as (CRC div (2^24)), which > doesn't rely on any specific byte ordering. That applies to the bit shifting semantics of BETA, of course. In general, it is not always like that. > The only difference is that > you can control the sign of the result when using shifts, whereas with > the div operation the sign depends on the type. (In the next release of > the Mjolner System, there are both signed and unsigned integers.) Are there any documents about the planned changes/extensions? > There is nothing in the CRC algorithm that depends on how integers are > laid out in memory (Often called Little Endian vs. Big Endian). Yes, it's just some implementation that may have that problem, like my Pascal version, which will produce different results on a big-endian machine. > No, Chars and Integers will remain, and so will assignment among them as > far as I know. Maybe you are confusing it with assignment of integers > to booleans. The compiler allows that for now, but warns that it may > stop doing so. You are right, I read up on it. One question, though: Will Chars remain the same, i.e. equivalent to a Byte, or will they be turned into Unicode characters, thus occupying two bytes of memory? > > version, both, for correctness and performance. Btw, my example was > > not a good demonstration for the need for bit-shifting, since it does > > really need it. I am sure, however, that there are such examples. > ^ > ^ NOT (Right?) Yes, sorry for the typo. > Agreed. The CRC example is not easy to do without the %Bxor though. That's why we need it. ;-) Karl ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Waclawek KD Soft Inc. * Phone: (905) 579-3443 * E-Mail: waclawek@idirect.com