1. vMac
Hey, I don't know if this is totally off the wall or what, but I
actually found a site that has a macintosh emulator. perhaps this can
help anyone working on some sort of euphoria port to mac easier?
http://www.vMac.org/
2. Re: vMac
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BDF170.8E6C1130
charset="iso-8859-1"
Noah Smith wondered:
> Hey, I don't know if this is totally off the wall or what,
> but I actually found a site that has a macintosh emulator.
> perhaps this can help anyone working on some sort of euphoria
> port to mac easier?
Actually, you need to own a Mac in order to legally load a Mac ROM onto the
machine for vMac, and even then, it's legally an iffy sort of thing.
Executor is a clean-room Mac emulator, but it's not 100% compliant.
I haven't been able to find any freeware Mac C compilers that I can load on
a Mac Classic. The closest I've seen is the Harvest C compiler, but that's
missing important include files. All the current Mac compilers that I've
seen won't run on a native 68K machine. 
-- David Cuny
------_=_NextPart_001_01BDF170.8E6C1130
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: vMac</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Noah Smith wondered:</FONT>
</P>
<P><FONT SIZE=3D2>> Hey, I don't know if this is totally off the =
wall or what, </FONT>
<BR><FONT SIZE=3D2>> but I actually found a site that has a =
macintosh emulator. </FONT>
<BR><FONT SIZE=3D2>> perhaps this can help anyone working on some =
sort of euphoria </FONT>
<BR><FONT SIZE=3D2>> port to mac easier?</FONT>
</P>
<P><FONT SIZE=3D2>Actually, you need to own a Mac in order to legally =
load a Mac ROM onto the machine for vMac, and even then, it's legally =
an iffy sort of thing. Executor is a clean-room Mac emulator, but it's =
not 100% compliant.</FONT></P>
<P><FONT SIZE=3D2>I haven't been able to find any freeware Mac C =
compilers that I can load on a Mac Classic. The closest I've seen is =
the Harvest C compiler, but that's missing important include files. All =
the current Mac compilers that I've seen won't run on a native 68K =
machine. </FONT></P>
<P><FONT SIZE=3D2>-- David Cuny</FONT>
</P>
</HTML>
------_=_NextPart_001_01BDF170.8E6C1130--
3. Re: vMac
David:
Yeah I know. I own a Mac 512, and I'm prolly going to get another Mac
Plus. I was just tryin' to help, ya know? You can get the source code
to the emulator, and I was just tryin' to point out that perhaps it
would shed some light on a mac port of euphoria. I dunno--I don't kno
anything about that sort o' thing.
snortboy
4. Re: vMac
Why not got a new desktop G3? Is RDS working on the PowerPC version of
EUPHORIA? I bet it would be just as easy, if not easier, to write than
the Win95/98 version.
Speaking of writing the language:
If you can't realisitically build an OS using a language such as
EUPHORIA, what are the ramifications of creating a language (EUPHORIA)
on top of a language (C), as RDS does with EUPHORIA?
How limited is EUPHORIA with C as its underlying structure thingie?
Just curious.
ck
Noah Smith wrote:
>
> David:
>
> Yeah I know. I own a Mac 512, and I'm prolly going to get another Mac
> Plus. I was just tryin' to help, ya know? You can get the source code
> to the emulator, and I was just tryin' to point out that perhaps it
> would shed some light on a mac port of euphoria. I dunno--I don't kno
> anything about that sort o' thing.
>
> snortboy
5. Re: vMac
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Oct 06, 1998
-
Last edited Oct 07, 1998
ck writes:
> If you can't realisitically build an OS using a language such as
> EUPHORIA, what are the ramifications of creating a language
> (EUPHORIA) on top of a language (C), as RDS does with EUPHORIA?
To write an operating system from scratch, you need to do
things with the hardware that can't be expressed in anything
but assembly language. You can't build an operating system
in pure C, i.e. with no escapes to assembly. Although UNIX,
for instance, might be 98% C, there are some things, such
as fiddling with virtual memory registers, that can only be done
with special machine instructions that a compiler would never emit.
You *could* write an operating system that was, say, 90% Euphoria
code, but I don't think you'd want to, because O/S performance is
usually extremely important.
> How limited is EUPHORIA with C as its underlying structure thingie?
I don't see any real limitations from using C.
You could also ask Pete Eberlein or David Cuny.
There are a few places where I insert some hand-coded
assembly into the C code to improve performance
or to do something dirty that can't be expressed in C.
One place where this arises is in exw where a C function
in a .DLL is called. In C, you can't code a call to a routine when you
don't know until run-time how many arguments to pass *or*
what type those arguments are. There's simply no way to express this.
So in exw I have to resort to some machine-level trickery that
fools the compiler into doing what I want.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
6. Re: vMac
- Posted by Hawke <mdeland at NWINFO.NET>
Oct 06, 1998
-
Last edited Oct 07, 1998
Robert Craig wrote:
>In C, you can't code a call to a routine when you
>don't know until run-time how many arguments to pass *or*
>what type those arguments are.
why is it that for the function parameters in this situation,
you cannot simply have a single pointer as your parameter,
and have that single pointer paramenter at runtime point
to an array of pointers to where each pointer at each array
element was a pointer to a parameter you wanted to pass?
you could then pick off each parameter at the beginning
of the function by assigning a temp variable to each of
the pointers located in the individual elements of that
array of pointers passed as the single parameter.
and btw, i used to do it all the time when i coded in
C for a situation whereby i was parsing user input of
sentences that contained nouns and verbs and targets
and actions and the like, and i never knew how long
that argument was going to be,
ergo: how many words each sentence would be.
so i designed all the dependent functions to simply
take one arguement, an array of pointers (holding individual
words) and picked them off as so:
word1=argument[1]
if (arguement[2]!=NULL)
{word2=argument[2]}
if (arguement[3]!=NULL)
{word3=argument[3]}
//and so on until i had enough to perform *that* function
(pardon syntax here, been a long long time)
or something to that effect.
now please, don't get me wrong here, i am not trying to
second guess father euphoria here (i am barely worthy of
being able to hold the shoeshine bottle for his shoeshine
boy), i'm simply asking a question as to why the above
technique cannot be used for passing parameters that
are 'undefined' until runtime... dat's all :)
--Hawke', verily unfit to be the spittle in a spitshine =)
7. Re: vMac
Robert Craig wrote:
>In C, you can't code a call to a routine when you
>don't know until run-time how many arguments to pass *or*
>what type those arguments are.
Hawke' replied:
> why is it that for the function parameters in this situation,
> you cannot simply have a single pointer as your parameter,
> and have that single pointer paramenter at runtime point
> to an array of pointers to where each pointer at each array
> element was a pointer to a parameter you wanted to pass?
Your solution is fine if you are the one writing both the
subroutine and the calls to it.
The problem in exw is that I have to set up a call to an
*arbitrary* C routine in a .DLL. The C routine was written by
someone else and it expects to receive a certain number of
arguments on the stack, each with a specific type such as
int, double, etc. If it isn't done correctly then the program will
likely crash.
Your Euphoria program tells exw at run-time what the
arguments to the C routine should be (see define_c_func()).
When you later call c_func(), exw has to set up the call stack
in the way that's expected by a WIN32 API call with that many
arguments of those types. The call stack is not something that you can
play with directly through C. You have to use a bit of
assembly code to manipulate it (the PUSH instruction for instance).
To the WATCOM C compiler it looks like I'm making a simple
call via a function pointer to a 0-argument C function. In fact, I've
already pushed your various arguments of various types onto the
call-stack via some assembly code, and magically it all works.
(Of course I crashed my machine numerous times trying to debug
this stuff.)
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
8. Re: vMac
- Posted by Hawke <mdeland at NWINFO.NET>
Oct 06, 1998
-
Last edited Oct 07, 1998
Robert Craig wrote:
>Your solution is fine if you are the one writing both the
>subroutine and the calls to it.
>The C routine was written by someone else
ah! i see now... heh, i ummmm ... i don't think i could
write something that handled that... heh.
at the very least, if i tried, the room would be quite
a noxious green from the lingering brainfarts... heh.
> To the WATCOM C compiler it looks like I'm making a simple
> call via a function pointer to a 0-argument C function.
sweet. quite nice tomfoolery.
thanks for the explanation... it helped --Hawke'
