Re: non-x86 development
David Cuny wrote:
> martin stachon wrote:
>
> > I am not sure if coding for 68k architecture
> > is a good idea. AFAIK, 68k is now not supported
> > by Apple. (The new OSes require at least G3).
> DOS isn't supported by Microsoft anymore, but I don't know that it's been
a
> serious deterrent to Euphoria.
I don't know much about MacOS low-level stuff.
(I've been programming on Mac only with HyperTalk,
nice language, something like VisualBasic, only one datatype,
you can freely insert 'a' , 'an', 'the' into code, = can be written as 'is'
etc...,
AppleScript is based on its syntax.), but I think the API
for MacOS <=9 is different than for MacOS X.
So you will have to write two versions of Eu for Mac.
It is possible to create programs with dual code (FAT) - 68k and PowerPC.
(With two CODE resources)
> > It is problem to port Eu to another Unix, so
> > porting it to Mac would be a big problem.
>
> I was under the impression that there were only two bits of
> architecture-specific code in Euphoria:
>
> 1. Bits encoding the type are endian-specific.
> 2. Numbers are assumed to be 32 bits.
What about some built-in routines - getenv, command_line.
> I would think that could be isolated with some #ifdefs. I would assume
that
> Robert uses sizeof() and other standard coding practices to insulate his
> code.
>
> > Translating the Eu code to other architecture
> > would be difficult, because some parts of code
> > are in ASM,
>
> Are they? Even if Euphoria generates in-line assembly, you could still add
> flags to suppress these optimizations on non x86 platforms. And we know
that
> Robert's had to port Euphoria to several compilers, so the code isn't
> specific to a single compiler's features.
>
> > and there are differences between the OSes -
> > MacOS <9 have no STDIN / STDOUT - so you have
> > to emulate console.
>
> These are automatically provided by most Mac C libraries. You end up
getting
> something that looks like a DOS console on a 68K Mac pretty much for free
> using Metrwerks, for example.
>
> > And you will have to add all this Mac specific code
> > to libraries - calling ROM routines (QuickDraw), calling
> > OS, working with resources etc.
>
> You have to do native calls under Linux and Windows as well.
>
> > I looked at few pieces of code, and MacOS
> > API seems more complicated to me than WIN32
> > API. You will have to read the Mac Programming
> > Bible. (very fat book)
>
> I don't think the Mac API is *that* much more complicated than Windows.
>
> > You may get to run some current generic
> > Eu progs, (after modifications like using
> > ':' instead of '\\', but creating GUI apps
> > would be difficult.
>
> No more difficult than on other platforms.
>
> > I wouldn't do this. It requires a lot work.
>
> I wouldn't make that assumption until seeing Robert's source. You could be
> right, but at this point, it's all speculation. When I get my copy, I hope
> to give it a whirl on an emulated 68K Mac.
>
> -- David Cuny
I don't know if Mac programmers would be interested.
They are used with C and beginners with AppleScript.
Eu for Mac would be isolated from other Eu world,
because you could run only some generic command-line apps,
(I don't know how would be emulated passing parameters via command line?)
And I am not sure if Mac users like console.
Very little libraries and programs would be for it.
(Like Eu for Linux - it has only four contributions in RUC)
But who knows ?
sephirot writes:
> when you decide to emulate a mac, just ask if you need anything. i've
> got a coupla large disk images(system software, downloads, MPW for
> programming, etc...), though i think i may have oversized the second
> one, but bzip2 should be able to handle it considering it's mostly empty
I would help you too (I have a 68000, 68030 and PowerPC 603 machine)
I am a fan of Mac. Especially I would like to see MacOS X, it combines
Unix with great GUI). But I had to move to PC because of cheaper
HW, more SW etc.
Martin Stachon
|
Not Categorized, Please Help
|
|
