[SOLVED] Oxygen's Equivalents to C, Pls?

[Charles Pegge]

I tried def pointer cell* but this macro does not work in prototypes, unfortunately.

PS: cell alignments are a bit wobbly:

In 32bit mode, the offset for string and car is 04 whereas for double and quad, it is 08. It should be okay though.



for bit maskable flags, we have a special form of enumeration: 1 2 4 8 ...

enum bit types { T_NUMBER, T_FLONUM,T_SVALUE,T_CONS }

[Mike Lobanovsky]

In 32bit mode, the offset for string and car is 04 whereas for double and quad, it is 08.

This isn't so, Charles. In my C structure which was meant for 32 bits only, the offset to char*, __i64, double, and _car is 4 bytes everywhere, since _flag is an unsigned long and not part of a union. Everything that's a multiple of 4 bytes is perfect alignment under 32 bits.

With _flag changed to sys for both 32 and 64 bits, the offset to these fields will be either 4 or 8 bytes, respectively, which means perfect alignment for the respective bitnesses.

we have a special form of enumeration

Thanks, Charles, I'm already aware of it.

[Charles Pegge]

Mike,

The general C rules for alignment are to align members to their own size. Thus 4 byte members align to the nearest 4 byte step, and 8 bit members to the nearest 8 bytes step. Hence the disparity between svalue and rvalue/ivalue offsets:

I base my info on Wikipedia which I admit is not always the most reliable source:

http://en.wikipedia.org/wiki/Data_structure_alignment

The type of each member of the structure usually has a default alignment, meaning that it will, unless otherwise requested by the programmer, be aligned on a pre-determined boundary. The following typical alignments are valid for compilers from Microsoft (Visual C++), Borland/CodeGear (C++Builder), Digital Mars (DMC) and GNU (GCC) when compiling for 32-bit x86:

A char (one byte) will be 1-byte aligned.
A short (two bytes) will be 2-byte aligned.
An int (four bytes) will be 4-byte aligned.
A long (four bytes) will be 4-byte aligned.
A float (four bytes) will be 4-byte aligned.
A double (eight bytes) will be 8-byte aligned on Windows and 4-byte aligned on Linux (8-byte with -malign-double compile time option).
A long long (eight bytes) will be 8-byte aligned.
A long double (ten bytes with C++Builder and DMC, eight bytes with Visual C++, twelve bytes with GCC) will be 8-byte aligned with C++Builder, 2-byte aligned with DMC, 8-byte aligned with Visual C++ and 4-byte aligned with GCC.
Any pointer (four bytes) will be 4-byte aligned. (e.g.: char*, int*)
The only notable differences in alignment for an LP64 64-bit system when compared to a 32-bit system are:

A long (eight bytes) will be 8-byte aligned.
A double (eight bytes) will be 8-byte aligned.
A long double (eight bytes with Visual C++, sixteen bytes with GCC) will be 8-byte aligned with Visual C++ and 16-byte aligned with GCC.
Any pointer (eight bytes) will be 8-byte aligned.

To get a consistent 4 byte data offset (on a 32bit system) the structure can be packed:

packed type cell
  sys    flag
  char*  svalue
  sys    keynum
  =
  sys    flag
  quad   ivalue
  =
  sys    flag
  double rvalue
  =
  sys    flag
  cell*  car
  cell*  cdr
end type

[Mike Lobanovsky]

Charles,

Then we are simply talking about different alignments. You're talking in terms of C defaults which are exactly as you say, and Wikipedia is perfectly correct here.

But I was talking from the perspective of precessor architecture where perfect alignment is the boundary of machine word, which is 4 and 8 bytes for 32- and 64-bit architectures, respectively, unless more stringent SIMD requirements are to be met. Failure to observe it may lead to complete disfunctioning of Pentium predictors, and the penalty may be as severe as two or three fold drop downs in app speed.

I was always remembering that my final target was OxygenBasic where it would all boil down to asm registers and offsets.

[Charles Pegge]

Yes, a consistent data offset would be useful for asm functions.

If you would like to award cell with an extra flag - this will solidify the structure for all systems.

type flags
int flag,flagx
end type

type cell
  flags
  char*  svalue
  sys    keynum
  =
  flags
  quad   ivalue
  =
  flags
  double rvalue
  =
  flags
  cell*  car
  cell*  cdr
end type

[Mike Lobanovsky]

The existing 32-bit int will be sufficient to implement the entire "numeric tower" plus chars and vectors. But we can leave the other int in place too for the sake of yet better alignment and call it dwReserved in the best MS Windows traditions. (re: Win32 Programmer's Reference, WinAPI Structures section)

BTW how would you refer to such flag -- cell dot flag or cell dot flags dot flag? The flags structure in cell seems to be anonymous in this notation.

[Mike Lobanovsky]

One more thing, Charles.

You advocate sys for use as a pointer. But sys is a signed quantity. Now suppose we have a pointer whose numeric value is close to the +/- boundary for a given sys bitness. Now suppose again that we have an overlay to this pointer that we need to increment with, say, p += 1 traversing a string or array in a loop, and sooner or later this incrementation will have to cross that boundary.

What do we do in such a hypothetic case? I'm afraid it would be a latent disaster.

[JRS]

[Charles Pegge]

Mike,

Good point to consider. In the context of pointers, it makes no difference whether sign-bit 31 is set or not. Inc/Dec/Add/Sub works the same way. It's all twos-complement arithmetic - so, if the OS/Memory supports it, you get the full 4 Gig (2^32) addressing range.

Simple experiment:

Code: [Select]

sys a
a=0x7fffffff
inc a
print hex a '80000000
inc a
print hex a '80000001

The difference between long and dword becomes significant when multiplying and dividing, however.

John,
At least we have larger screens to gaze at

[JRS]

At least we have larger screens to gaze at.

Bad news for the cosmetics industry. We all look the same in a Tweet. 

[Mike Lobanovsky]

Charles,

I think you're doing what I expected you to do, which was falling into my deliberate trap of simplification. In fact, I was expecting you to remind me of multiplication and division. Let's leave out the latter though for the time being.

Now how would you suggest we should mimic the indexing of a matrix in a language that supports only one array dimension? Correct, by way of multiplying the span of matrix width by index height and adding index width if we're talking C-style row-major matrices, or the span of matrix height times index width plus index height, if talking classic BASIC column-major matrices.

Now suppose our matrix is well in excess of 2GB of memory which would not be uncommon for a database application. Unfortunately to us, those 2GB would be exactly where the aforementioned +/- borderline lies. So, our times index height or times index width may easily change the sign of addition to the base pointer value.

If this weren't so then what one would ever need unsigned data types for in the first place?

[Mike Lobanovsky]

At least we have larger screens to gaze at

That's simply because we have poorer, aging eyesight.

We all look the same in a Tweet. 

Which of course explains the missing Twitter button.

[Mike Lobanovsky]

(Charles, I'm pushing you gently towards introducing unsigned syses into the language.)

[Charles Pegge]

Mike,

Generally speaking, the maximum o2 memory allocation size is 2^30, because it uses ole strings. But leaving that aside for a moment..

spanning 4 gig memory

with index literals, which resolve to a [reg+offset], oops!
but using a long index:
With an array of bytes > 0x70000000, we are in trouble
With an array of words, we can do it (base 0 : i=0x7fffffff)
With an array of rgb (a plausible scenario) no problem
Any types larger than 2 bytes, okay

I've checked the asm code for these types.

Code: [Select]

type rgb byte r,g,b

function f(sys p)
=================
word w at p
rgb  c at p
word a
byte b
sys i
'#show a=w[0x80000000]  ' :(
'#show a=w[i]           ' :)
'#show b=c[i].r         ' :)
end function

PS: sys variables can be cast where necessary, but I have never had to.

Code: [Select]

dword a,b
sys i
#show a=b*b
#show (dword) i=b*b


[Mike Lobanovsky]

Generally speaking, the maximum o2 memory allocation size is 2^30, because it uses ole strings.

I'd call it delusion, Charles, for you can never know what a user has up his sleeve for a complacent developer...

I, for one, am using malloc() for nanoscheme allocations.  And I'm not the naughtiest user among the living. Using malloc(), I can always be sure that my arrays and strings would be aligned on a 4-byte boundary rather than at arbitrary bytes within the memory pools of carelessly written custom memory managers.

That's just one example of the perpendicularity of our visions. OxygenBasic is too good to be squeezed into the Procrustean bed of weird OLE strings.


(So what about unsigned syses, Charles? Just to make your users feel themselves safer? mul and div instead of imul and idiv for sys pointers? )