Author Topic: Punix (Read 43201 times)

christop · « **on:** February 26, 2011, 02:19:01 pm »

Recently I started experimenting with floating-point emulation on the 68K calculators, specifically in my own OS, Punix. (I'm new to this forum, and I haven't talked about Punix lately in other TI forums either, so for those who don't know what Punix is, it's a Unix-like OS--complete with features like preemptive multitasking and a VT220 terminal emulator--that I'm writing for the TI-92+ and maybe the TI-89)

Here's a little background on floating-point emulation. First of all, the 68000 processor has no support for FP hardware (such as the 68881 floating-point unit, or FPU). Only the later CPU's in the family (68020, '40, '60) do. However, the 68000 does have an exception vector (the so-called "F-line" or "Line 1111 emulator" exception) which allows for software FP operations. This is basically an FPU emulator, and this is what I have done. Needless to say, the software FP emulation is far slower than a real FPU by about an order of magnitude in the best case.

The 68881 and 68882 are the FPU's of choice for the 68020 (and also for the FPU-less versions of the '40), so this is what I chose to emulate. This FPU supports several integer and floating-point formats (byte integer, word integer, long integer, single-precision float, double-precision float, extended-precision float, and packed decimal float) and several addressing modes (AFAICT, the same modes as the 68000). The internal FP registers of the 6888x FPU's are 80-bit extended-precision (but stored in 96 bits), as described on this page: http://en.wikipedia.org/wiki/Extended_precision

By contrast, the TI-AMS on the 68k calcs uses an 80-bit SMAP II BCD floating-point format, which has less precision, a smaller range, and is slower to calculate than extended precision. (Single precision is smaller and faster than the others, but it also has the least precision and smallest range.)

Anyway, after a few hours of work, I implemented basic instruction decoding and the execution of a few simple FP instructions, notably FTST, FNEG, and FBcc (which is analogous to the regular Bcc instructions). Here is some demo code showing what my FPU emulator can handle so far:

Code: [Select]

| print the FP type using the current FP condition codes
printfptype:
	movem.l %a0-%a3,-(%sp)

	| test for nan
	fbngle  1f	| NGLE = not greater, less, or equal

	| test for zero/not zero
	fbneq   2f	| NEQ = not equal
	pea.l   4f      | 0
	bra     3f
2:	pea.l   5f      | x
0:	bra     3f

1:	pea.l   9f      | nan

	| test for sign (doesn't recognize negative zero)
3:	fblt    2f      | LT = less than
	pea.l   7f      | +
	bra     0f
2:	pea.l   6f      | -
0:	pea.l   8f

	jbsr    printf
	lea.l   (3*4,%sp),%sp

	movem.l (%sp)+,%a0-%a3
	rts

4:	.asciz "0"
5:	.asciz "x"
6:	.asciz "-"
7:	.asciz "+"
8:	.asciz "%s%s\n"
9:	.asciz "nan"

| here is the main entry point for the demo
| fputest() is called from a user-space driver program
	.global fputest
fputest:
	move    #-5,%d0

	| %Dn.b
	fneg.b  %d0,%fp0
	bsr     printfptype

	| (d16,%pc)
	fneg.x  (11f,%pc),%fp1
	bsr     printfptype

	| (An)
	lea     11f,%a3
	fneg.x  (%a3),%fp2
	bsr     printfptype

	| (An)+
	fneg.x  (%a3)+,%fp3
	bsr     printfptype
	fneg.x  (%a3)+,%fp4
	bsr     printfptype
	fneg.x  (%a3)+,%fp5
	bsr     printfptype
	fneg.l  (%a3)+,%fp6
	bsr     printfptype
	fneg.l  (%a3)+,%fp7
	bsr     printfptype
	fneg.w  (%a3)+,%fp0
	bsr     printfptype
	fneg.w  (%a3)+,%fp1
	bsr     printfptype
	fneg.b  (%a3)+,%fp2
	bsr     printfptype
	fneg.b  (%a3)+,%fp3
	bsr     printfptype

	| -(An)
	fneg.b  -(%a3),%fp4
	bsr     printfptype
	fneg.b  -(%a3),%fp5
	bsr     printfptype
	fneg.w  -(%a3),%fp6
	bsr     printfptype
	fneg.w  -(%a3),%fp7
	bsr     printfptype
	fneg.l  -(%a3),%fp0
	bsr     printfptype
	fneg.l  -(%a3),%fp1
	bsr     printfptype

	rts
11:	.long 0x7fffffff,0x40000000,0x00000000  | nan
12:	.long 0x7fffffff,0x00000000,0x00000000  | +inf
	.long 0xffffffff,0x00000000,0x00000000  | -inf
13:	.long 7
	.long -7
	.word 5
	.word 0
	.byte 3
	.byte 0

This code tests a few different addressing modes (register, indirect, address register indirect, address register indirect with pre-decrement/post-increment) and integer/float formats (extended-precision, long, word, byte). My emulator cannot handle single- or double-precision or packed decimal formats yet, so I haven't tested those.

The output of this code is "-x" for a negative number, "+x" for a positive number, "+0" for zero (the test code doesn't differentiate between positive and negative zero), or "+nan" for NaN.

Here is a screenshot of this demo code in action:

(You may notice that it displays "+x" for both infinities, whereas it should display "-x" for negative infinity. I already fixed this bug but didn't update the screenshot.)

Each emulated instruction takes between about 600 and 1400 cycles, which is between 8.5 and 20 KFLOPS (kilo floating-point operations per second) with a 12MHz clock rate. According to http://en.wikipedia.org/wiki/Motorola_68881 the 68881 runs at 160 KFLOPS at 16MHz, which would be about 120 KFLOPS at 12MHz. As you can see, this FPU emulator is about 1/10 as fast as a real FPU. (Take these with a grain of salt as I haven't really started on the more computationally expensive operations like multiplication and division).

Since this demo only tests simple operations (fneg is basically just flipping a single bit), most of the time in these simple FP operations is spent in decoding the instruction itself. I might also make the bare floating-point routines available to user programs (so they can do, eg, "bsr fneg" to negate (%a0) and put the result in (%a1)) to remove the instruction decoding time, but for now I'll stick with this FPU emulation.

Edit: fixed note about the bug regarding +/- infinity. I was off by one looking at the display.
Edit again: negative infinity bug is squished! I didn't check the sign for infinity and nan in the FTST code (which FNEG does implicitly)
Edit thrice: I just realized that an extended-precision value with a maximum exponent (0x7fff) is a NAN only if the fraction (excluding the MSB of the fraction) is non-zero. If only the MSB of the fraction is set, it's an infinity, not a NAN. I fixed my code to reflect this correction. Read this for (many) more details: http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf

DJ Omnimaga · « **Reply #1 on:** February 26, 2011, 02:23:58 pm »

Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?

Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...

christop · « **Reply #2 on:** February 27, 2011, 12:52:18 am »

Quote from: DJ_O on February 26, 2011, 02:23:58 pm

Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?

Punix probably will not be able to run any applications that were designed for TI-AMS (TI's OS). It's basically a new OS from scratch (with some bits of low-level code from PedroM, though), so it won't be compatible with TI-AMS. It may be possible to write a TI-AMS emulator for it (kind of like Wine for running Windows applications in Linux), but I'm not too concerned about it at this point.

Quote

Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...

Nope, I think I tried registering on this site a few years ago but never completed the registration for some reason.

Since my first post I managed to get all formats (except for packed decimal) working. Here are the new test data in my demo:

Code: [Select]

11:     .long 0x7fff0000,0x40000000,0x00000000  | nan
        .long 0x00000000,0x00000000,0x00000000  | ?? (packed decimal)
12:     .long 0x7ff80000,0x00000000  | nan (double)
        .long 0x40450000,0x00000000  | 42 (double)
        .long 0x7fc00000  | nan (single)
        .long 0x42280000  | 42 (single)
        .long 42
        .word 42
        .byte 0

The packed decimal data is recognized, but it's not converted to extended-precision correctly yet. Right now it is gracefully converted to NAN. I'll have to figure out a way to convert 17 BCD digits to a 64-bit binary value efficiently. Then there's the matter of converting from extended precision back to all the different formats... And of course, multiplying two 64-bit integers to get a 128-bit product, or dividing a 128-bit integer by a 64-bit integer to get a 64-bit quotient. Then there's computing natural logarithms and exponents with floating point! Fun times!

I also have to test the rest of the addressing modes too (I tested only 6 out of 12), such as address register indirect with index register and 8-bit displacement (d8,%An,%Xn). Actually, that is one of the more complicated addressing modes, so overall it's not that bad. The other equally complicated one is the same but uses the program counter instead of an address register (d8,%PC,%Xn).

Lionel Debroux · « **Reply #3 on:** February 27, 2011, 12:55:46 pm »

Hi Christopher

Nice to see you registering on Omnimaga, and to see you working on new stuff for Punix.

christop · « **Reply #4 on:** February 27, 2011, 10:33:51 pm »

Quote from: Lionel Debroux on February 27, 2011, 12:55:46 pm

Hi Christopher
Nice to see you registering on Omnimaga, and to see you working on new stuff for Punix.

Thanks. I'm working on Punix very slowly these days. I've got about a dozen (probably not an exaggeration) other projects, family, and school, plus I'm looking for work. I guess you could say my load average is pretty high. My brain needs more cores!

DJ Omnimaga · « **Reply #5 on:** February 27, 2011, 11:57:08 pm »

Quote from: christop on February 27, 2011, 12:52:18 am

Quote from: DJ_O on February 26, 2011, 02:23:58 pm
Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?
Punix probably will not be able to run any applications that were designed for TI-AMS (TI's OS). It's basically a new OS from scratch (with some bits of low-level code from PedroM, though), so it won't be compatible with TI-AMS. It may be possible to write a TI-AMS emulator for it (kind of like Wine for running Windows applications in Linux), but I'm not too concerned about it at this point.

Quote
Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...

Nope, I think I tried registering on this site a few years ago but never completed the registration for some reason.

Ah ok thanks for the info. I guess someone could write an emulator later maybe, but if there are games that don't use a single AMS command or whatever they are called on 68K calculators I bet they wouldn't be too hard to port.Also I assume of of your goal for this OS will be a much smaller file size than TI-AMS to give as much free RAM/archive as possible to the user? I wonder how much flash memory does a TI-89 and a TI-89T has in total...

As for the site, I guess you probably signed up on the other Omnimaga board back in 2006-07 but never posted. I remember at one point we had registrations disabled, though, because of spambots, then later we added a different registration step to block them, while still allowing people to sign up, but some people would never complete it. I think I might have seen you in #tcpa or something, too.

AngelFish · « **Reply #6 on:** February 28, 2011, 12:30:09 am »

Would I be correct in presuming that these FP numbers conform to IEE 754 standards if they can return NaN?

Lionel Debroux · « **Reply #7 on:** February 28, 2011, 02:30:37 am »

I'm following here on your post at http://tichessteamhq.yuku.com/topic/4795/Suboptimal-code-for-shifting-a-long-long . You already know first-hand what happens, on that board, to topics related to maintenance and evolution of TI-68k development environments

Yes, it would certainly be possible to make GCC generate better code. Probably not trivial though, since it requires fiddling with a very outdated version of the the well-known-as-hairy GCC code base - and modifying it further will only make the large TIGCC/GCC4TI patch harder to maintain or port to a newer version of GCC (which wouldn't even necessarily generate better code anyway - we've already seen a number of pessimizations brought by newer versions)...
But seriously, I think that if you want optimized code, write it into ASM - it's easier than modifying GCC, and guaranteed to remain effective

You should also use explicit bxx.s branches (2 bytes), because just "bxx" will yield 4-byte branches

For the record (not directly related to the topic, but I can't commit it for now), here's the incomplete breakdown I did in ~2h by going through the patch:

Quote

* win32 changes: config.guess, gcc/config/i386/xm-mingw32.h, gcc/gcc.c, libcpp/files.c
* fiddling with default attributes: gcc/attribs.c, gcc/c-common.c, gcc/c-common.h, gcc/c-decl.c, gcc/c-lang.c, gcc/c-tree.h, gcc/langhooks-def.h, gcc/langhooks.h, gcc/system.h
* changes to the GCC built-in functions, among which is __builtin_ER_throw: gcc/builtin-attrs.def, gcc/builtins.c, gcc/builtins.def
* stkparm / regparm parameter passing: gcc/builtins.c, gcc/c-decl.c, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k-protos.h, gcc/c-parser.c, gcc/c-tree.h, gcc/function.c, gcc/function.h
* SMAP II BCD support: gcc/c-cppbuiltin.c, gcc/c-format.c, gcc/combine.c, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-modes.def, gcc/config/m68k/predicates.md, gcc/config/smapbcd.h, gcc/config.gcc, gcc/convert.c, probably gcc/c-pretty-print.c, gcc/dwarf2out.c, gcc/emit-rtl.c, probably gcc/explow.c, gcc/expr.c, gcc/final.c, gcc/fold-const.c, gcc/genmodes.c, gcc/machmode.def, gcc/optabs.c, gcc/output.h, gcc/print-rtl.c, gcc/print-tree.c, gcc/real.c, gcc/real.h, gcc/rtlanal.c, gcc/simplify-rtx.c, gcc/tree.c, gcc/tree-pretty-print.c, gcc/varasm.c
* global cast constructors / compound literals: gcc/c-decl.c, gcc/common.opt, gcc/flags.h, gcc/varasm.c
* -fno-function-cse changes: gcc/cfgexpand.c, gcc/gimplify.c, gcc/tree-ssa-dom.c, gcc/tree-ssa-pre.c
* kill global include paths, usage of environment variables, hard-coded prefixes, etc.: gcc/c-incpath.c, gcc/c-opts.c, gcc/cppdefault.c, gcc/gcc.c
* changes related to forward or backslashes in paths: gcc/c-incpath.c, gcc/toplev.c
* multi-line strings: probably gcc/c-lex.c, probably gcc/c-ppoutput.c, libcpp/internal.h, libcpp/lex.c
* constant pools, section merging, moving stuff between bss/data/rodata: gcc/common.opt, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-none.h, gcc/config/m68k/m68k.opt, gcc/config/m68k/m68k-ti.h, gcc/flags.h, gcc/varasm.c
* register-relative addressing & global register variables: gcc/common.opt, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/final.c, gcc/gcse.c, gcc/ifcvt.c, gcc/opts.c
* default to not initializing the BSS section: gcc/common.opt
* debugging support: maybe gcc/config/dbxcoff.h, gcc/config/m68k/m68k.c, gcc/dwarf2.h, gcc/dwarf2out.c, gcc/toplev.c, gcc/varasm.c
* OPTIMIZE_ROM_CALLs: gcc/config/m68k/m68k.c
* no long branches: gcc/config/m68k/m68k.c + external patcher (with a "FIXME: should be moved to GCC")
* platform-specific changes such as greater optimization, or different printf/scanf/memset/etc., or peepholes: gcc/c-format.c, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-none.h, gcc/config/m68k/m68k.opt, gcc/config/m68k/m68k-ti.h, gcc/config/m68k/predicates.md, gcc/expr.c, gcc/opts.c, gcc/postreload.c, gcc/stmt.c, gcc/tree-object-size.c
* no-auto-octals: gcc/c.opt, gcc/c-opts.c, libcpp/include/cpplib.h, libcpp/init.c
* changes to default warnings: gcc/c-decl.c -> what with "Each undeclared identifier is reported only once" ?, gcc/c-opts.c
* reverting the removal of casts-as-lvalues: gcc/c-parser.c, gcc/c-typeck.c, gcc/tree.h
* gcc/c-pretty-print.c -> what's the second hunk ?
* reference the TIGCC infrastructure which does not make public the bug report content: gcc/diagnostic.c, gcc/version.c
* a warn_unused_result-related change: gcc/gimplify.c
* a patch related to using hard register variables as an asm input: gcc/loop.c
* gcc/sdbout.c -> ?
* inlining-related fix: gcc/tree-inline.c
* a change without comments in gcc/tree-ssa-ccp.c
* pragma poison (why ?): libcpp/directives.c
* binary numbers (0b...) support: libcpp/expr.c
* SYMSTR optimization: libcpp/macro.c

After the optimization passes in the library and startup code performed before GCC4TI 0.96 Beta 9, before GCC4TI 0.96 Beta 10 and afterwards in SVN, I found some optimization potential on a dozen library routines several weeks ago. I haven't committed because I haven't tested enough - doing so requires building up a test suite because there's none (merely compiling the examples, about a year ago, turned up 4 bugs).

christop · « **Reply #8 on:** February 28, 2011, 01:52:39 pm »

Quote from: DJ_O on February 27, 2011, 11:57:08 pm

Ah ok thanks for the info. I guess someone could write an emulator later maybe, but if there are games that don't use a single AMS command or whatever they are called on 68K calculators I bet they wouldn't be too hard to port.Also I assume of of your goal for this OS will be a much smaller file size than TI-AMS to give as much free RAM/archive as possible to the user? I wonder how much flash memory does a TI-89 and a TI-89T has in total...

Wel, it also depends on whether the game does stuff like installs its own interrupt handler. I believe TI-AMS allows user programs to run code in supervisor mode without too many restrictions (there are some restrictions on writing to Flash, though), but Punix keeps a clear separation of kernel (supervisor) mode and user mode. Also if it tries to read and write directly to the keyboard I/O ports (these are actually mapped to memory addresses in 68k), it would interfere with the normal keyboard handling code. So... it all depends on how much a program tries to do that is allowed by TI-AMS but not by Punix. In a way, it would be similar to porting a game or application from MS-DOS to Windows or Unix/Linux, since MS-DOS allows direct hardware access and the others don't.

Yes, one of my goals is to leave as much RAM and FlashROM space to the user as possible. The FlashROM is the filesystem, which leaves all of RAM for kernel buffers and user programs. Incidentally I recently tested how much contiguous memory I could allocate from userspace using malloc(). I started trying to allocate 256K (this is how much RAM the TI-89/92+ have total), reduced the amount by 1024 bytes until the malloc() succeeded, and then printed that amount (and free()ing the memory, of course!). In my current test setup, that amount came out to 202752 bytes, or 198 Kbytes. In the past I cleared out some large static memory allocations in the kernel, but there is still some kernel memory that I can free up for user programs here and there.

The TI-89 and TI-92+ have 2MB of FlashROM, I think the TI-89T has 4MB. Currently the Punix kernel uses two pages of FlashROM, or 128K, which leaves 1.875 MB for the filesystem (which I'm still writing). Some of the filesystem will be used for system binaries and configuration files, so the user should have maybe 1.5 MB for their files. Compare this to 700K (or 2.7MB on the TI-89T) of FlashROM available to the user in TI-AMS. All that math software takes up a lot of space (and poorly optimized code doesn't help either.)

Quote from: DJ_O on February 27, 2011, 11:57:08 pm

As for the site, I guess you probably signed up on the other Omnimaga board back in 2006-07 but never posted. I remember at one point we had registrations disabled, though, because of spambots, then later we added a different registration step to block them, while still allowing people to sign up, but some people would never complete it. I think I might have seen you in #tcpa or something, too.

That sounds about right. I think that is what happened.

christop · « **Reply #9 on:** February 28, 2011, 02:09:55 pm »

Quote from: Qwerty.55 on February 28, 2011, 12:30:09 am

Would I be correct in presuming that these FP numbers conform to IEE 754 standards if they can return NaN?

Yes, you would be correct. The 68881 (and, by extension, my FPU emulator) support IEEE754 single, double, and extended precision floating-point numbers (32, 64, and 80 bit, respectively). Extended-precision values are stored in 96 bits internally and in memory, however (16 bits padding). The 68881 also supports a 96-bit packed-decimal format, which is similar to the TI BCD float format. I'm still debating whether I should support that format since it probably will not even be used.

My emulator probably won't round extended-precision values correctly since that format uses 64 bits for the fraction, and rounding requires an extra bit or two of precision to do properly. Single and double precision will probably be rounded correctly though.

Jim Bauwens · « **Reply #10 on:** February 28, 2011, 04:00:37 pm »

This is just awesome! I've been following the progress of punix for years, and its great to see progress!
I've tried to compile it once, but I failed (probably I did something stupid). The screenshot show that you have already written a shell for it, which makes me even more happy

christop · « **Reply #11 on:** February 28, 2011, 06:26:39 pm »

Quote from: jimbauwens on February 28, 2011, 04:00:37 pm

I've tried to compile it once, but I failed (probably I did something stupid). The screenshot show that you have already written a shell for it, which makes me even more happy

It probably wasn't you. I stupidly left Punix un-compilable since r202, which was almost a year ago now (yikes! where does the time go?). I fixed that problem 3 days ago in r211. Note that the Makefiles only work under *nix systems, or possibly with Cygwin/MinGW under Windows, since they use *nix shell commands (eg, date and tail). If you're using Windows, that might be another reason it failed. If you're using Linux, try compiling it again, and let me know how that goes.

The shell that you see is really just a mockup. It reads a command and has a big chunk of if (!strcmp(cmd, "somecommand")) statements. It doesn't search the filesystem (since there is none yet) or do anything fancy like piping or redirection. I'm using it to test various functionality of the kernel or some library routines.

Once I get a filesystem working and can execute binaries from the filesystem, I'll probably just port an existing Bourne-compatible shell to it... something like ash, zsh (not the TI-8x shells with the same/similar names

), or Busybox. With Busybox, I would also get a lot of standard utilities built-in. W00t!

christop · « **Reply #12 on:** February 28, 2011, 07:41:01 pm »

As a curiosity, I downloaded and compiled BusyBox 1.18.3 using the TEST_config_nommu configuration, and it produced a 519296-byte stripped binary. Obviously this would be too large for the calculator, but it also includes far more utilities than are needed:

Code: [Select]

Currently defined functions:
	[, [[, add-shell, addgroup, adduser, ar, awk, base64, basename,
	bbconfig, blockdev, bootchartd, bunzip2, bzcat, bzip2, cal, cat, catv,
	chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt,
	cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack,
	cut, date, dc, dd, delgroup, deluser, devmem, df, diff, dirname, dnsd,
	dnsdomainname, dos2unix, dpkg, dpkg-deb, du, echo, ed, egrep, env,
	envdir, envuidgid, expand, expr, fakeidentd, false, fgrep, find,
	flashcp, flock, fold, fsck, fsck.minix, fsync, ftpd, ftpget, ftpput,
	fuser, getopt, getty, grep, gunzip, gzip, halt, hd, head, hexdump,
	hostid, hostname, httpd, hush, id, ifdown, ifup, inetd, init, inotifyd,
	install, iostat, ipcalc, ipcrm, kill, killall, killall5, klogd, last,
	length, less, linuxrc, ln, logger, login, logname, logread, lpd, lpq,
	lpr, ls, lspci, lsusb, lzcat, lzma, lzop, lzopcat, makedevs, makemime,
	man, md5sum, mesg, microcom, mkdir, mkfifo, mknod, mkpasswd, mkswap,
	mktemp, more, mountpoint, mpstat, msh, mt, mv, nbd-client, nc, nice,
	nmeter, nohup, nslookup, od, passwd, patch, pgrep, pidof,
	pipe_progress, pkill, pmap, popmaildir, poweroff, powertop, printenv,
	printf, ps, pscan, pwd, rdate, rdev, readlink, readprofile, realpath,
	reboot, reformime, remove-shell, renice, reset, resize, rev, rm, rmdir,
	rpm, rpm2cpio, run-parts, runlevel, runsv, runsvdir, script,
	scriptreplay, sed, sendmail, seq, setsid, setuidgid, sh, sha1sum,
	sha256sum, sha512sum, sleep, smemcap, softlimit, sort, split,
	start-stop-daemon, strings, stty, su, sulogin, sum, sv, svlogd, sync,
	sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd,
	test, tftp, tftpd, time, timeout, top, touch, tr, true, tty, ttysize,
	udpsvd, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop,
	unxz, unzip, usleep, uudecode, uuencode, vi, vlock, volname, wall,
	watch, wc, wget, which, who, whoami, xargs, xz, xzcat, yes, zcat

With only a shell and about a dozen of the most common utilities compiled in (eg, cat, echo, ls), it would probably be about 10k-20k, which I think is reasonable.

That's a while off, though. I need to finish the filesystem (as I mentioned already) and develop a development environment for compiling programs for Punix (TIGCC has too many TI-AMS assumptions built in, and it can't output the appropriate binaries for Punix either--besides the Punix kernel itself, of course).

DJ Omnimaga · « **Reply #13 on:** February 28, 2011, 07:55:10 pm »

Will betas and the final version be available in binary form too? It might be a bit too much to recompile it everytime a new build comes out, but a lot of less tech-savy calculator/computer users tend to have troubles compiling softwares, as we could see with Ndless 2.0 with the flood of questions asking for help on how to compile Ndless due to errors.

Jim Bauwens · « **Reply #14 on:** March 01, 2011, 03:39:31 am »

I'm using Linux, but right now I don't have much time on my hands. I will see I can compile it somewhere later this month.
Its so cool that your system is following the POSIX guidelines, as there are so many little programs build for *nix systems that will work without changing the code.

Author Topic: Punix (Read 43201 times)

christop

Punix

DJ Omnimaga

Re: Punix

christop

Re: Punix

Lionel Debroux

Re: Punix

christop

Re: Punix

DJ Omnimaga

Re: Punix

AngelFish

Re: Punix

Lionel Debroux

Re: Punix

christop

Re: Punix

christop

Re: Punix

Jim Bauwens

Re: Punix

christop

Re: Punix

christop

Re: Punix

DJ Omnimaga

Re: Punix

Jim Bauwens

Re: Punix