Other things besides drivers OpenFirmware can do.
April 14, 2006 7:02 PM Subscribe
Can you make something besides a driver run in OpenFirmware?
I know someone's going to answer this fairly quickly, but is it possible to both write a small network program (think: dial home), and embed it into the OpenFirmware of a Powerbook, without seriously causing some dammage, but making it almost impossible to remove?
Furthermore, is Forth a difficult langauge to learn from the perspective of someone that understands C+?
I know someone's going to answer this fairly quickly, but is it possible to both write a small network program (think: dial home), and embed it into the OpenFirmware of a Powerbook, without seriously causing some dammage, but making it almost impossible to remove?
Furthermore, is Forth a difficult langauge to learn from the perspective of someone that understands C+?
FORTH is very different from C++, for the reasons that Steven has given. The paradigms in FORTH are very different, you'll spend a lot of time thinking about stacks, because FORTH revolves around them.
I wouldn't go as far as to call it 'an abortion' - it's designed to be extremely compact and expressive. In fact, it's as expressive as you make it. FORTH has an ANSI standard, but you really want to create new words (FORTH for functions, kind of) that perform the actions you want. If you have a deep love of refactoring you'll probably enjoy FORTH, it's a big game among developers to use the fewest words to acheive feats of stack acrobatics.
I'm kind of biased. My first paying programming job was at a little company in Ross-On-Wye that developed counting tools for industrial laundry systems. The boss was a FORTH fan, so we programmed everything in FORTH. Including the Windows-based visualization applications. I wouldn't want to be doing that stuff today, but it's good to be aware of a type of programming that's far removed from the methods in vogue today.
I can't really tell you much about OpenFirmware and what you can do with it, but in theory you can access the hardware through it, so in theory you could achieve what you want to do.
posted by lowlife at 7:57 PM on April 14, 2006
I wouldn't go as far as to call it 'an abortion' - it's designed to be extremely compact and expressive. In fact, it's as expressive as you make it. FORTH has an ANSI standard, but you really want to create new words (FORTH for functions, kind of) that perform the actions you want. If you have a deep love of refactoring you'll probably enjoy FORTH, it's a big game among developers to use the fewest words to acheive feats of stack acrobatics.
I'm kind of biased. My first paying programming job was at a little company in Ross-On-Wye that developed counting tools for industrial laundry systems. The boss was a FORTH fan, so we programmed everything in FORTH. Including the Windows-based visualization applications. I wouldn't want to be doing that stuff today, but it's good to be aware of a type of programming that's far removed from the methods in vogue today.
I can't really tell you much about OpenFirmware and what you can do with it, but in theory you can access the hardware through it, so in theory you could achieve what you want to do.
posted by lowlife at 7:57 PM on April 14, 2006
"A small network program"? I don't know how much program space you have available but it seems like you're underestimating the amount of work it takes to get a functional TCP/IP networking stack implemented. And on top of that you'd have to hand-code the ethernet driver as well, which means implementing all the lower level protocols like ARP. It sounds like it would take a grey-bearded seasoned hardware wizard a good six months of full-time work to implement something that extensive and still squeeze it into a bootloader.
posted by Rhomboid at 8:15 PM on April 14, 2006
posted by Rhomboid at 8:15 PM on April 14, 2006
Forth is primarily designed to write extremely fast programs in a very, very small space. As SCDB is saying, it's not that far removed from raw assembly, and is only a little slower, but lets you pack code a lot more tightly than normal assembly routines. (you can do the same tricks it uses manually, of course, but that would take a very long time to write and debug.) It was in vogue in the era of 1Mhz 8-bit machines, because it let you write useful, fast programs, sometimes in just a few hundred bytes. Calling it an 'abortion' is unfair, as it solved the problems it was meant for exceedingly well. It's just mostly a waste of time in the era of multicore, multi-gigahertz machines.
If there's any language that would let you implement a TCP/IP stack in the limited space in most firmware, it would be Forth. But, as Rhomboid is saying, it would require serious, serious beard-stroking.
posted by Malor at 8:28 PM on April 14, 2006
If there's any language that would let you implement a TCP/IP stack in the limited space in most firmware, it would be Forth. But, as Rhomboid is saying, it would require serious, serious beard-stroking.
posted by Malor at 8:28 PM on April 14, 2006
Does apple's Open Firmware implementation support network booting, or anything like that? If so then at least some basic networking functionality is already in place, in which case it might be possible to send a UDP packet to a fixed IP.
posted by Good Brain at 8:29 PM on April 14, 2006
posted by Good Brain at 8:29 PM on April 14, 2006
If the end goal is to "dial home" then that implies that it would have to jump through all the hoops of acquiring a DHCP lease, autoconfiguring IP address, netmask, gateway address, and full IP connectivity in general -- which would be significantly more work than just broadcasting to the local LAN segment ala TFTP.
posted by Rhomboid at 8:39 PM on April 14, 2006
posted by Rhomboid at 8:39 PM on April 14, 2006
Response by poster: I imagined this would be some serious stuff, but this is the kind of feedback I needed. You've answered what I really wanted to know - that it's capable, but I'm going to need to find someone to do the heavy lifting for me.
Thanks!
posted by plaidrabbit at 9:19 PM on April 14, 2006
Thanks!
posted by plaidrabbit at 9:19 PM on April 14, 2006
Best answer: It would probably be more accurate to say that it MIGHT be possible, with a Forth wizard at the keyboard. It mostly depends on how much room there is for custom code in Open Firmware, and how complete the built-in Forth is. As a wild-assed guess based on just a little Forth experience, if it has 32k of code space, that's almost certainly enough, and 16k might do. Forth is _very_ efficient.
I don't think the Intel Macs are using Open Firmware anymore, though, so keep in mind that if you're planning to turn something like this into an actual, for-sale product, it will have a very, very limited audience. If you're not planning to sell it, it would be a lot cheaper to just buy a new laptop if you lose yours.
posted by Malor at 5:50 AM on April 15, 2006
I don't think the Intel Macs are using Open Firmware anymore, though, so keep in mind that if you're planning to turn something like this into an actual, for-sale product, it will have a very, very limited audience. If you're not planning to sell it, it would be a lot cheaper to just buy a new laptop if you lose yours.
posted by Malor at 5:50 AM on April 15, 2006
Best answer: This doesn't answer the question you posed, but from quick research, EFI can be used to this. I didn't run across any good references quickly, but from wikipedia's page on EFI:
This is an optional intermediate step in the booting process which can be used to run diagnostic or configuration utilities, or even play CDs or DVDs without a complete operating system.
This may be an interesting way to add traditionally userspace code underneath the OS level.
posted by rcs at 10:56 AM on April 15, 2006
This is an optional intermediate step in the booting process which can be used to run diagnostic or configuration utilities, or even play CDs or DVDs without a complete operating system.
This may be an interesting way to add traditionally userspace code underneath the OS level.
posted by rcs at 10:56 AM on April 15, 2006
Response by poster: I guess you guys have been reading my previous questions. :)
rcs/Malor - thank you. I should be looking at EFI instead, I guess.
posted by plaidrabbit at 7:43 PM on April 15, 2006
rcs/Malor - thank you. I should be looking at EFI instead, I guess.
posted by plaidrabbit at 7:43 PM on April 15, 2006
This thread would be incomplete without a mention of Amit Singh's "The Towers of Hanoi in Open Firmware", which is exactly what it sound like.
It looks like he has a telnet server running in OpenFirmware.
posted by dammitjim at 2:30 PM on April 17, 2006
It looks like he has a telnet server running in OpenFirmware.
posted by dammitjim at 2:30 PM on April 17, 2006
This thread is closed to new comments.
FORTH isn't really a high level language. The right way to think of it is that it's a high level assembly language for a stack architecture machine which is simulated by the Forth runtime system. It isn't correct to refer to Forth as being interpretive, because it's a different approach than that. But it isn't compiled, either. And FORTH code doesn't look anything like C++, because everything, everything, is in postfix notation.
You enter expressions in RPN, for instance. And if you want to call a function and pass it parameters, you have to push the parameters on the stack before making the call. If the function has a return value, it leaves it on the stack when it returns.
In some ways it's even closer to the hardware than C. It doesn't directly support arrays, for instance. If you want to implement an array, you do your own address offset calculations.
And if you leave the stack dirty, all hell breaks loose. Bug rates per thousand lines of code for FORTH are more similar to ASM than to C++, and like ASM each line of code does much less. So debugging FORTH code is an exercise in frustration.
FORTH is an abortion, and there's a damned good reason it never took off. But like all computer abortions, there is (or used to be) a hard core of fans who thought (and think) that it's God's Gift to Computer Science.
Is it a difficult language to learn? Depends on the person, I would say, but if you've never written any significant amount of assembly language, I suspect you'll have a really hard time with it. Your experience with C++ will be a hindrance, not a help, because nothing in FORTH is remotely like the same functionality in C++.
posted by Steven C. Den Beste at 7:19 PM on April 14, 2006