deven@rpi.edu (Deven T. Corzine) (03/23/90)
On 19 Mar 90 14:16:57 GMT, peter@sugar.hackercorp.com (Peter da Silva) said:
Peter> In UNIX, you have to use several expressions:
Peter> _*.[ch] _*.bak ck*.[ch] ck*.bak *test*.[ch] *test*.bak
Deven> For csh users: {_,ck,*test}*.{[ch],bak}
Deven> AmigaDOS's (x|y|z) syntax is directly analogous to csh's {x,y,z}.
Peter> No, it isn't. In most cases it can be used the same way, but
Peter> it's not identical.
Peter> The csh {,} syntax is parsed before wildcarding is done. It's
Peter> not really an alternation operator, like the Amiga (|) syntax
Peter> supports. For example, expanding {core,*.o} will produce the
Peter> string "core" whether or not there is a file matching that
Peter> pattern. This can be useful, but it's not the same thing.
That's true. You're right there. But, it's close enough for casual
use.
Peter> Also, as other people have pointed out, there's still no
Peter> closure operator. How about all file names of the form cx
Peter> followed by any number of digits?
Peter> cx#(0|1|2|3|4|5|6|7|8|9)
Can't. But, it IS nicer to be able to use "[0-9]" instead of
"(0|1|2|3|4|5|6|7|8|9)"...
Peter> Also, of course, it's not available in scripts.
No reason why some Unix shell shouldn't allow full regexps for
globbing. They just don't, usually. :-) [tradition, y'know.]
Deven> Granted, AmigaDOS wildcards are flexible and powerful, but I
Deven> find them less convenient to use than Unix wildcards, under
Deven> most circumstances.
Peter> Which is why my original message, that started this whole chain
Peter> off, suggested using UNIX wildcards interactively and the more
Peter> powerful Amiga wildcards in scripts.
Well, I'd like to be able to use Unix wildcards in scripts too, unless
I really need the closure or some such.
Peter> That suggestion, by the way, was that *all* uses of wildcards
Peter> be marked explicitly, and all arguments not marked as wildcards
Peter> not be wildcarded. On the Amiga, for example, anything not
Peter> enclosed in parentheses would be treated literally.
I would like to be able to do "Join *.c wx#(y|z) ab#c.* to '*'" and
have it work as expected. That is, first *.c is Unix semantics,
second wx#(x|y) is AmigaDOS semantics, third ab#c.* is a combination,
and the fourth (fifth) '*' is an escaped wildcard, so it would open
the console as * normally does for BCPL...
Peter> Anyway, Deven, get back to coding up Amigix & quit wasting time
Peter> on News. :->
News isn't as hard as debugging... *sigh*
Well, I starting building the shared library yesterday. Layed down
all the structure and wrote a few functions. Used the sample.library
from the 1.3 Includes & Autodocs RKM as a guide. Right now, the
functions in the library [and this will change] are malloc(),
calloc(), AllocMem() [not necessarily externally visible], and free().
The allocators call Exec's AllocMem for the actual block and for a
MemList block to describe it. All memory allocated is tacked onto the
task's tc_MemEntry list, which means it will be freed by RemTask when
the task exits or if another task removes it. The sick Unix semantic
of freeing a block of memory and still using it is supported.
Implementation is as follows.
The free() function will scan the tc_MemEntry list for a MemList with
a single block with a matching address pointer. If it finds it, it
does a Remove() and AddHead() on it, and sets the node type to -1 as a
flag. When any of the memory functions is called (malloc(), calloc(),
free()), it first calls a subroutine which checks the node type of the
first node in the tc_MemEntry list of the task, and if it is -1, then
it does a RemHead() and FreeEntry() on it. If the node type is not
-1, it does nothing. In the event on an exit, then RemTask will still
clean up the "freed" block, since it is still in the tc_MemEntry list,
and RemTask doesn't care what the node types are.
I have written these functions completely (in assembly) but I have not
tested or debugged them yet. I still need to write other memory-
related functions, such as realloc(), ReallocMem() [a tougher one; I
may be forced to muck around in the system memory lists directly],
bcopy(), bzero(), bswap() [nonstandard perhaps, but obvious, no?] and
bcmp()... I need to add in the SwapMem functions I wrote recently.
If I make AllocMem() externally visible as a library vector, [I
probably will] then I will add a FreeMem() to go with it.
For those sitting there thinking "Why?" -- this AllocMem is like the
malloc() in that is saves the block in the tc_MemEntry structure for
tracking, but allows a requirements argument. The FreeMem() will
probably NOT free memory if it can't find the matching block in the
tc_MemEntry list -- might be an invitation for a "freeing memory
already freed" GURU.
Why write bcopy() when there is exec.library CopyMem()? Because bcopy
will handle arbitrary overlapping memory blocks, which CopyMem() does
not. [might as well deal with that issue ONCE so you can later forget
it and use bcopy without worrying about if the blocks overlap.]
Bcopy() will be be efficient. Bzero() will simply zero a block of
memory efficiently. bswap() will swap two blocks of memory
efficiently, arbitrarily overlapping. Bcmp() will compare two blocks
of memory, also efficiently. And so forth.
Then I need to deal with the I/O (fd) structure, and functions for
that, and I need to add the System Task, and _then_ I can attack
fork() itself. Or maybe vfork() first. I'll half-implement exec().
(Initially.)
It gets a little complex.
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.peter@sugar.hackercorp.com (Peter da Silva) (03/23/90)
In article <DEVEN.90Mar22125624@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: > Peter> cx#(0|1|2|3|4|5|6|7|8|9) > Can't. But, it IS nicer to be able to use "[0-9]" instead of > "(0|1|2|3|4|5|6|7|8|9)"... Yeh, but you can't do cx#(0|1|2|3|4|5|6|7|8|9).(obj|bak|lnk|lbk) The point is that regular expressions are more powerful than wildcards. And the Amiga "wildcards" are regular expressions. > No reason why some Unix shell shouldn't allow full regexps for > globbing. They just don't, usually. :-) [tradition, y'know.] Well, that's the point ain't it? > I would like to be able to do "Join *.c wx#(y|z) ab#c.* to '*'" and > have it work as expected. That is, first *.c is Unix semantics, > second wx#(x|y) is AmigaDOS semantics, third ab#c.* is a combination, > and the fourth (fifth) '*' is an escaped wildcard, so it would open > the console as * normally does for BCPL... Ack. Give me consistency. > Why write bcopy() when there is exec.library CopyMem()? Because bcopy > will handle arbitrary overlapping memory blocks, which CopyMem() does > not. How about putting this in the C library level, and implement sbrk() for the lower level. malloc isn't a system call... Also, how about using ANSI C functions (memcpy, memmov, memcmp, etc) instead of the non-standard BSD ones? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
deven@rpi.edu (Deven T. Corzine) (03/24/90)
On 23 Mar 90 02:59:17 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> Yeh, but you can't do cx#(0|1|2|3|4|5|6|7|8|9).(obj|bak|lnk|lbk) Granted. Peter> The point is that regular expressions are more powerful than Peter> wildcards. And the Amiga "wildcards" are regular expressions. True enough. Deven> No reason why some Unix shell shouldn't allow full regexps for Deven> globbing. They just don't, usually. :-) [tradition, y'know.] Peter> Well, that's the point ain't it? Yup. Deven> I would like to be able to do "Join *.c wx#(y|z) ab#c.* to '*'" Deven> and have it work as expected. Peter> Ack. Give me consistency. Give me flexibility. Deven> Why write bcopy() when there is exec.library CopyMem()? Deven> Because bcopy will handle arbitrary overlapping memory blocks, Deven> which CopyMem() does not. Peter> How about putting this in the C library level, and implement Peter> sbrk() for the lower level. malloc isn't a system call... Also, Peter> how about using ANSI C functions (memcpy, memmov, memcmp, etc) Peter> instead of the non-standard BSD ones? Because I don't want to force a static data segment. Under Unix, malloc calls sbrk() which calls brk(). Under Amigix, malloc() will call AllocMem() and sbrk() and brk() will be be either sumplistic or dummy-implemented. As for the ANSI memory functions... well, the BSD ones aren't _that_ nonstandard. But no reason not to have both ANSI and BSD ones. For example, bcopy() and memcpy() can be the same routine, just two different ways to call it. (2 stub routines & 2 #pragmas) I know the arguments are in a different order. The stub routines and pragmas can handle loading the registers in a different order without having to change the actual routine. One problem I have is that I don't have any really good reference for ANSI library functions... As for library calls vs. system calls, the division may not be the traditional ones. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
peter@sugar.hackercorp.com (Peter da Silva) (03/25/90)
> Peter> How about putting this in the C library level, and implement > Peter> sbrk() for the lower level. malloc isn't a system call... Also, > Peter> how about using ANSI C functions (memcpy, memmov, memcmp, etc) > Peter> instead of the non-standard BSD ones? > Because I don't want to force a static data segment. Under Unix, > malloc calls sbrk() which calls brk(). Under Amigix, malloc() will > call AllocMem() and sbrk() and brk() will be be either sumplistic or > dummy-implemented. Sbrk really has the same semantics as AllocMem. On segmented machines it's happy to allocate memory segments and give you memory in chunks that aren't contiguous with each other. You would be quite justified in making sbrk a dummy front end for AllocMem(). > As for the ANSI memory functions... well, the BSD ones aren't _that_ > nonstandard. But no reason not to have both ANSI and BSD ones. For > example, bcopy() and memcpy() can be the same routine, just two > different ways to call it. No, that's bcopy and memmov. memcpy doesn't check argument order. > One problem I have is that I don't have any really good reference for > ANSI library functions... You can get the draft standard from Global Engineering Documents. > As for library calls vs. system calls, the division may not be the > traditional ones. I would recommend providing a traditional division, just for the sake of programmer sanity. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
deven@rpi.edu (Deven T. Corzine) (03/26/90)
On 25 Mar 90 15:18:05 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> Sbrk really has the same semantics as AllocMem. On segmented Peter> machines it's happy to allocate memory segments and give you Peter> memory in chunks that aren't contiguous with each other. You Peter> would be quite justified in making sbrk a dummy front end for Peter> AllocMem(). I just looked again. Okay, no problem. sbrk can point to malloc(), perhaps, or a routine that will call malloc() or free() appropriately. But brk() will have to be dummy-implemented. Peter> No, that's bcopy and memmov. memcpy doesn't check argument order. How so? Presumably there is a source and destination... Deven> One problem I have is that I don't have any really good Deven> reference for ANSI library functions... Peter> You can get the draft standard from Global Engineering Documents. I do have friends with K&Rv2, but I don't know how accurate it is. What is Global Engineering Documents? Deven> As for library calls vs. system calls, the division may not be Deven> the traditional ones. Peter> I would recommend providing a traditional division, just for Peter> the sake of programmer sanity. Logically, sure. Technically, well... they'll likely be mixed in the actual Exec libraries. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.