Menu
▾
▴
emerson-general — General mailing list for all Emerson design discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(3) |
Dec
|
|---|
|
From: Lucas M. <luc...@ro...> - 2005-11-04 18:33:36
|
We were planning to have an abstract streams output concept that allows things like 3d graphics to be outputted through it. I don't see why this cant just be an api that you can call like any other. Adding extra opcodes just increases complexity. Also, I think you are overestimating the importance of being able to write drivers in the VM. The whole concept is that its abstracted from hardware. I'm all for having native plug-ins for the client program to allow support of extra I/O devices but they would expose themselves to the VM in a high-level way. -Lucas |
|
From: Fefer A. <Ale...@ex...> - 2005-11-04 04:20:33
|
What are your thoughts on an OUT instruction (so the virtual machine can directly output data to a predefined "output port" (which, in reality, is an API that we specify for people to implement an I/O interface to the "outside world", such as drivers to Windows/Linux devices, etc.) We have to start thinking about how we're going to implement I/O to and from the virtual machine. Any ideas? -Alex. |
|
From: Lucas M. <luc...@ro...> - 2005-11-01 19:12:18
|
Um, dude, are you alive? <poke> <poke> Did you manage to get anything done? -Lucas _____ From: eme...@li... [mailto:eme...@li...] On Behalf Of Alex Fefer Sent: Friday, October 28, 2005 9:24 PM To: Emerson Mailing List Subject: [Emerson-general] Yes!! My internet is back! I'm going to spend the rest of the day working on Emerson. Expect some big updates! -Alex. |
|
From: Alex F. <ale...@ka...> - 2005-10-29 01:24:29
|
My internet is back! I'm going to spend the rest of the day working on Emerson. Expect some big updates! -Alex. |
|
From: Lucas M. <luc...@ro...> - 2005-10-24 03:36:45
|
Damn that sucks! Anyway, basically the only good code is the stuff we wrote first, the network bundle code. It has some references to python but we could easily remove them since it's not python-dependent. As for the other stuff, we might as well keep it since we have basically unlimited space (who knows it might be in the "making-of" documentary...lol). If you have nothing to do you could make new repo/project/whatever on our sf account and check the cleaned up bundle stuff in. Btw, did you managed to get anywhere on the formal VM spec? -Lucas |
|
From: <af...@en...> - 2005-10-24 02:13:06
|
Ah! Sorry I haven't replied. Those bastards at NEC (actually, they're not bastards, it was my fault) cut off my internet and it won't be back up for another couple of days. Actually, my internet is awesome - it's FTTH (fiber to the home) and blindingly fast; the problem is that I misread a letter they sent me and I forgot to tell them how I was intending to pay. ;) So right now I just have my connection at work at least for the next day or two. The idea about the "scope table" is great, and it'd be very easy to implement. By the way, what do we do about the code that's currently in the CVS repository? A lot of it's old and dependent on our scary Python work. How much is usable, and how much isn't? I think before we start any serious work, we should clean out the repository. -Alex. Quoting Lucas Magder <luc...@ro...>: > > Ok, sounds good. As for unsafe code/pointers, no they shouldn't be there. > This follows my logic for removing the threading opcodes; People can and > will code in pure assembly, there should be no way to formulate any kind of > opcode sequence that would cause a security, stability, or data corruption > issue. Obviously accessing things by string name is too slow but I was > thinking of having a "scope table" for each scope, which matches names, and > real C++ pointers. Then in the asm code it would be based on indexes in the > scope table. So you have pseudo pointers but you can't access anything not > in your scope. Also this table (the C++ structure I mean) would have a > pointer to its parent scope table to allow multiple nested scopes. > > -Lucas > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Emerson-general mailing list > Eme...@li... > https://lists.sourceforge.net/lists/listinfo/emerson-general > ---------------------------------------- This mail sent through www.mywaterloo.ca |
|
From: Lucas M. <luc...@ro...> - 2005-10-19 21:49:08
|
Ok, sounds good. As for unsafe code/pointers, no they shouldn't be there. This follows my logic for removing the threading opcodes; People can and will code in pure assembly, there should be no way to formulate any kind of opcode sequence that would cause a security, stability, or data corruption issue. Obviously accessing things by string name is too slow but I was thinking of having a "scope table" for each scope, which matches names, and real C++ pointers. Then in the asm code it would be based on indexes in the scope table. So you have pseudo pointers but you can't access anything not in your scope. Also this table (the C++ structure I mean) would have a pointer to its parent scope table to allow multiple nested scopes. -Lucas |
|
From: <af...@en...> - 2005-10-19 06:35:00
|
Agreed, so we can leave out the new class and static-call opcodes. As for arrays, making them objects instead of some kind of special case is a better idea. We should try to box as much as possible within c++ objects so we don't have all these weird scenarios we have to deal with later. So in our situation, arrays are just classes? I'll make a formal instruction set reference specification later, probably this weekend. Are we supporting pointers/"unsafe code"? -Alex. Quoting Lucas Magder <luc...@ro...>: > > That looks good but why do we need a new class opcode? Didn't we decide that > metadata would describe types not code itself. Also we don't need two call > opcodes, if we treat a class as an instance of a metaclass that is > instantiated when the class definition is loaded, then we only need a > non-static call opcode, you call it from a different thing. Also, can't we > just make arrays objects instead of having a special case?, plus you > shouldn't be able to mess with threading. It should be completely automatic. > If it's not, then someone could, for example, purposely leave out lock > opcodes in hand coded asm to cause a data corruption attack. > > As for adding opcodes, we need assignment, flat function calls, and a return > > opcode at least. > > -Lucas ---------------------------------------- This mail sent through www.mywaterloo.ca |
|
From: Lucas M. <luc...@ro...> - 2005-10-18 19:53:31
|
That looks good but why do we need a new class opcode? Didn't we decide that metadata would describe types not code itself. Also we don't need two call opcodes, if we treat a class as an instance of a metaclass that is instantiated when the class definition is loaded, then we only need a non-static call opcode, you call it from a different thing. Also, can't we just make arrays objects instead of having a special case?, plus you shouldn't be able to mess with threading. It should be completely automatic. If it's not, then someone could, for example, purposely leave out lock opcodes in hand coded asm to cause a data corruption attack. As for adding opcodes, we need assignment, flat function calls, and a return opcode at least. -Lucas |
|
From: Alexander F. <af...@en...> - 2005-10-17 11:41:26
|
Here's a rough list of potential opcodes for the Emerson virtual machine. What are your thoughts? Arithmetic: add subtract multiply divide remainder negate shift AND OR XOR increment decrement compare Classes, Arrays: new class new instance of class new array get object reference from array of objects store object reference in array of objects get value from array store value in array get array length what about type conversions? float-to-integer, etc? Execution: goto throw expection set breakpoint jump if equal jump if not equal jump if greater than jump if less than jump if greater than or equal to jump if less than or equal to jump if null (how are we defining "null" within the namespace, by the way? is it just zero, or some magical voidness?) temporarily lock object (let's say you're sorting an array; you don't want another thread to access it) unlock object call static method call instance method branch to address? Stack manipulation: Push value onto stack Pop value off stack Swap top two values on the stack There's a whole crapload I'm probably forgetting or neglecting. Change whatever you like and add whatever you like! Regards. -Alex. ---------------------------------------- This mail sent through www.mywaterloo.ca |
|
From: Alex F. <ale...@ka...> - 2005-10-15 06:58:53
|
Testing testing. Hey Lucas, can you re-send your last message? I forgot to uncheck the maximum email size through the list. Regards -Alex. |
2 messages has been excluded from this view by a project administrator.
