6 ms·

Although some of the implications require experience to understand, I'd say it already is in "relatively plain English", you simply haven't been exposed to the

by nknight 15y ago

Although some of the implications require experience to understand, I'd say it already is in "relatively plain English", you simply haven't been exposed to the vocabulary and concepts necessary. Trying to explain in any detail would basically be reproducing Wikipedia, so here are some links: http://en.wikipedia.org/wiki/Program_counter http://en.wikipedia.org/wiki/Program_counter http://en.wikipedia.org/wiki/Word_(computer_architecture) http://en.wikipedia.org/wiki/Word_(computer_architecture) http://en.wikipedia.org/wiki/JMP_(x86_instruction) http://en.wikipedia.org/wiki/JMP_(x86_instruction) http://en.wikipedia.org/wiki/NOP http://en.wikipedia.org/wiki/NOP http://en.wikipedia.org/wiki/Orthogonal#Computer_science http://en.wikipedia.org/wiki/Orthogonal#Computer_science http://en.wikipedia.org/wiki/Address_space http://en.wikipedia.org/wiki/Address_space http://en.wikipedia.org/wiki/Memory-mapped_I/O http://en.wikipedia.org/wiki/Memory-mapped_I/O http://en.wikipedia.org/wiki/Interrupt http://en.wikipedia.org/wiki/Interrupt And no, don't expect Python anytime soon. Expect a C compiler, FORTH, possibly some sort of Pascal, but a highly dynamic language is unlikely. The system is too resource-constrained to make it practical. A static language that looks kind of like Python isn't out of the question, but it won't do a lot of the things you expect from Python, Ruby, PHP, or Perl.

SoftwarePatent 15y ago
Reading all these wikipedia pages is going to kill at least an hour of productivity today :/
- SimHacker 15y ago
  And it will enable countless years of productivity!
- ch0wn 15y ago
  Depends on what you define as being productive. I personally perceive learning as something productive.
akavel 15y ago
> a highly dynamic language is unlikely Lua, perhaps? There was an article how to reduce its binary size, for an older version of the language (Lua 4.0): http://www.lua.org/notes/ltn002.html http://www.lua.org/notes/ltn002.html With no reductions, and for x86 assembly, it started at ~64KB, so not very useful here; but after dropping standard libraries and parser, they got to ~24KB. Now however, some further questions arise I'm not sure about: - whether such a virtual machine, when without parser, would be anyhow more useful than the underlying system alone? - how much the binary code would be bigger when compiled for the "DCPU-16" instruction set instead of x86?
- nknight 15y ago
  Lua is a good place to start! And the VM minus parser is useful, though it may make debugging harder. You simply write out the bytecode and upload that. The VM is only part of the problem, though. I consider the bigger problem to be memory management. A garbage collected language operating reliably in 128KB? I'm deeply skeptical.
  - quadhome 15y ago
    While I don't think Lua would be the choice, it's the quantity of garbage that matters: "Historically, languages intended for beginners, such as BASIC and Logo, have often used garbage collection for heap-allocated variable-length data types, such as strings and lists, so as not to burden programmers with manual memory management. On early microcomputers, with their limited memory and slow processors, BASIC garbage collection could often cause apparently random, inexplicable pauses in the midst of program operation. Some BASIC interpreters such as Applesoft BASIC on the Apple II family, had terribly inefficient garbage collectors for strings which repeatedly scanned the string descriptors for the string having the highest address in order to compact it toward high memory. This one-string-at-a-time processing loop resulted in O(N * N) time performance in the number of strings, which would introduce a pause more than one minute long into the execution of string-intensive programs. A replacement garbage collector for Applesoft BASIC published in Call-A.P.P.L.E. (January 1981, pages 40–45, Randy Wiggington) identified a group of strings in every pass over the heap, reducing a pause of two minutes into less than a second depending on the size of the group. Other approaches were published, but none ever made it into a new revision of the BASIC interpreter." http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Availability http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...
ac 15y ago
A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128k limitation was intentional, to make programming the computers more interesting. Anyway, I'm actually looking forward to seeing what kind of clever solutions the players come up with.
- nknight 15y ago
  The ANSI C library is quite small. It originates in an era when 128KB of RAM was reasonably roomy. To this day, there are C libraries designed to fit comfortably within that size. Most of the library code will never even be present anyway. Your (statically-linked) binary will simply contain those functions actually used, which is likely to be a small subset of what is available.
- jmaygarden 15y ago
  An RTOS won't be of much use without interrupts. You could implement coroutines, but preemptive scheduling is not possible.
  - javert 15y ago
    Moreover, it would be very surprising if low-latency or deterministic timing properties would actally be useful in the game.

by nknight 15y ago

SoftwarePatent 15y ago

Reading all these wikipedia pages is going to kill at least an hour of productivity today :/

SimHacker 15y ago
And it will enable countless years of productivity!
ch0wn 15y ago
Depends on what you define as being productive. I personally perceive learning as something productive.

akavel 15y ago

> a highly dynamic language is unlikely Lua, perhaps? There was an article how to reduce its binary size, for an older version of the language (Lua 4.0): http://www.lua.org/notes/ltn002.html http://www.lua.org/notes/ltn002.html With no reductions, and for x86 assembly, it started at ~64KB, so not very useful here; but after dropping standard libraries and parser, they got to ~24KB. Now however, some further questions arise I'm not sure about: - whether such a virtual machine, when without parser, would be anyhow more useful than the underlying system alone? - how much the binary code would be bigger when compiled for the "DCPU-16" instruction set instead of x86?

nknight 15y ago
Lua is a good place to start! And the VM minus parser is useful, though it may make debugging harder. You simply write out the bytecode and upload that. The VM is only part of the problem, though. I consider the bigger problem to be memory management. A garbage collected language operating reliably in 128KB? I'm deeply skeptical.
- quadhome 15y ago
  While I don't think Lua would be the choice, it's the quantity of garbage that matters: "Historically, languages intended for beginners, such as BASIC and Logo, have often used garbage collection for heap-allocated variable-length data types, such as strings and lists, so as not to burden programmers with manual memory management. On early microcomputers, with their limited memory and slow processors, BASIC garbage collection could often cause apparently random, inexplicable pauses in the midst of program operation. Some BASIC interpreters such as Applesoft BASIC on the Apple II family, had terribly inefficient garbage collectors for strings which repeatedly scanned the string descriptors for the string having the highest address in order to compact it toward high memory. This one-string-at-a-time processing loop resulted in O(N * N) time performance in the number of strings, which would introduce a pause more than one minute long into the execution of string-intensive programs. A replacement garbage collector for Applesoft BASIC published in Call-A.P.P.L.E. (January 1981, pages 40–45, Randy Wiggington) identified a group of strings in every pass over the heap, reducing a pause of two minutes into less than a second depending on the size of the group. Other approaches were published, but none ever made it into a new revision of the BASIC interpreter." http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Availability http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...

ac 15y ago

A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128k limitation was intentional, to make programming the computers more interesting. Anyway, I'm actually looking forward to seeing what kind of clever solutions the players come up with.

nknight 15y ago
The ANSI C library is quite small. It originates in an era when 128KB of RAM was reasonably roomy. To this day, there are C libraries designed to fit comfortably within that size. Most of the library code will never even be present anyway. Your (statically-linked) binary will simply contain those functions actually used, which is likely to be a small subset of what is available.
jmaygarden 15y ago
An RTOS won't be of much use without interrupts. You could implement coroutines, but preemptive scheduling is not possible.
- javert 15y ago
  Moreover, it would be very surprising if low-latency or deterministic timing properties would actally be useful in the game.