World: r3wp

Maybe I should call it "Linux32" and hold the 64-bit versions clean... 
So there can be a future "Linux", which is 64-bit.

The current Linux version is compiled under Linux Mint 12 "Lisa" 
32-bit.

No standard, I fear. You could use the compiler's (GCC's) target 
machine verbatim, though.

Like:

$ gcc -dumpmachine
i686-apple-darwin10

For GCC, you can see get the target machine tuple with the "-dumpmachine" 
flag. This would give you stuff like:
i486-linux-gnu
x86_64-linux-gnu
arm-linux-gnueabi
i686-apple-darwin10
i586-mingw32msvc

Yep.

Not sure if that's the best idea, but maybe worth considering.

Yes, worth considering. But do we like to type that in scripts?

My Win32 say:

$ gcc -dumpmachine
i686-pc-mingw32

I think for scripts we want a small helper library with various predicate 
functions.

REBOL use this: version.revision.update.platform.variation
See: http://www.rebol.com/docs/version-numbers.html
I could add a system/version/variation at some point.

A helper lib sounds like a good idea, then I could make changes later.

Like: linux? windows? 32bit? 64bit? etc.

ARM, X86, MIPS? There's more than just OS and bits...

That can be handled with system/version/variation, which I'll add.

Then you might consider having the platform be a word of just the 
platform name, but also include a platform-plus-hardware word in 
a different field. This would make specialty code that switches on 
the OS (for API stuff) or full platform (for selecting native code) 
much easier to write.

So platform: 'windows but variation: 'windows-intel-32

Or whatever your naming convention is.

I see your point. It's not easy to find a good way, that is sure 
to cover all future possibilities.

I went for strings, so it could be e.g. "Mac OS X" and not the word 
mac-os-x.

Maybe platform could be, 'macosx, 'linux and 'windows and variation 
something like 'intel-32, 'intel-64, etc. Or do we need a third variable?

So maybe no variation, but instead processor and bits.

Can you SWITCH on two words at once?

In fact, there's so much more than OS and bits, that it's hardly 
worth trying to come up with an all-encompassing scheme.

Others have tried, and failed.

One of the common situations where you need to do platform-specific 
stuff is in loading prebuilt libraries, and those depend on the platform 
and processor variant. That means that selecting one requires selecting 
both, or all 3 if you have a seperate bits field. One SWITCH is better 
than 3.

I would like to have platform, which is kinda the OS, I guess. And 
the consequence of what Andreas just said, then the rest should just 
go into one variable, variation.

case [all [linux? arm?] [...] all [linux? amd64?] [...] ...]

Can you SWITCH on two words at once?


Yes, SWITCH can handle that. I don't have CASE yet, but probably 
will.

Something like this?

switch [platform variation] [
	[linux intel-32] [do something]
	[linux intel-64] [do domething else]
]

(sorry, that was bad syntax, but you get the idea)

switch reduce ... and without the first blocks inside. Just e.g. 
linux intel-32 [...]

Is it correct, REBOL can't handle that?

w> platform: 'linux
== linux
w> variation: 'intel-32
== intel-32

w> switch reduce [platform variation] [linux intel-32 [print "Found 
it!"]]
Found it!

SWITCH is a mezzaning in World (see cortex.w) and just uses FIND.

*mezzanine*

New release at https://github.com/Geomol/World

- The new routine spec is implemented.
- Compiling blocks should be fixed. I also added a test for this.

- system/version changed. Should be able to handle all future platforms/bits/processors/makers/etc.

- Added libs/version.w to help with deciding platform and version.
- Other fixes.

- Now cortex_alpha.pdf is updated too.
- And new version of cortex.w , where HELP can handle routines.

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]

Compiling blocks is not 100%. Working on it.

Geomol: this is such nice stuff!

:)

My first experience with LLVM.


I tried to compile World with llvm-g++ under OS X. When compiling 
with gcc, I normally use -O2 option. I compared performance with 
the Mandelbrot test. Between compilations, I deleted all .o files 
and executable, so new compile started from scratch.

Compiling with llvm-g++:

With -O2 option, file size grow to 105% and execution time extend 
to 105% (slower).

With -O3 option, file size grow to 106% and execution time is the 
same.

With -O4 option (also Link Time Optimization), file size extend to 
122% and execution time grow to 107% (slower).


Then I tried to compile with gcc and -O3 option. Now file size grow 
to 105% and execution time shortened to 85% (faster).

Has anyone had similar experience with LLVM?

(And I thought, LLVM was much better, but maybe I do something wrong 
or miss some option!?)

Porting to LLVM took less than an hour. It's mainly changes, because 
LLVM is very strict about types, when checking e.g. unsigned against 
signed values. etc.

You mean porting to "clang"?

There is a /usr/bin/llvm-g++ command under OS X. The man page say:
llvm-gcc uses gcc front-end and gcc's command line interface.

So maybe it isn't "clang"!? I'm not sure. It's my first real experience 
with LLVM.

There also is a /usr/bin/clang
Maybe I should try compile with that.

By the way, why haven't you used LLVM for building World? As it is 
VM-based, LLVM would have been a good match.