headers
rod | 1 Dec 2010 20:53
Picon

vm scheduling question

I am finding that system calls from the dis vm are quite slow on my
embedded board. A significant amount of time is being taken up by
context switching in "acquire". In order to acheive reasonable
streaming data speeds for a "real time" system, or even just to copy a
file efficiently, I need to try and minimise the time between the end
of one i/o operation and the start of another. 

This is the sequence of events that befall a vm thread when it makes
the very first system call:

First we call "release" to relinquish the vm. Because there is only
one kproc running, the one created at initialisation time whose
context we are running in, "release" kindly creates a new kproc and
sets the idle flag to 1. Let's call the new one kproc2 and the
original one kproc1. The idle flag indicates that for now the vm has
no kproc associated with it.  We make the system call.  When the
system call blocks for i/o, the kernel schedules kproc2 and it's entry
point,"vmachine", gets called.  Subsequently, in "startup", the idle
flag gets set to zero, indicating that the vm now has a kproc, and we
enter the idle loop and make a call to sleep which causes the kernel
to suspend kproc2.  Before long the i/o completes and the kernel
schedules kproc1.  The system call returns and "acquire" is called to
attempt to recapture the vm. This is where things get long-winded. The
idle flag tells us that the vm already has a kproc, so we have no
choice but to put ourselves on the vm queue, block, wake kproc2 and
force a reschedule.  On waking, Kproc2 ascertains that there is now a
kproc on the vmq and calls "iyield".  "Iyield" puts kproc2 onto the
idlevmq, blocks it, readies kproc1 which is at the head of the vm
queue and forces a reschedule.  Kproc1 runs and returns to the vm.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Sickel | 5 Dec 2010 21:21
Favicon

macosx build

After way too many times of missing this build error on MacOSX, I finally traced it down.  The crux of the error
has been the use of $LIBFILES instead of $LIBNAMES as an $O.$CONF dependency.  This change now allows for a
clean 'mk all' from the $ROOT of the source tree.  The rest of the diff is just a little clean up to make it more
in-line with other port mkfiles.

-jas

[tamu:inferno/emu/MacOSX] jas% hg diff mkfile
diff -r da3a06d528f7 emu/MacOSX/mkfile
--- a/emu/MacOSX/mkfile	Sat Dec 04 17:16:36 2010 -0600
+++ b/emu/MacOSX/mkfile	Sun Dec 05 14:18:00 2010 -0600
 <at>  <at>  -1,8 +1,6  <at>  <at> 
 SYSTARG=MacOSX
-#OBJTYPE=power
 <../../mkconfig
 SYSTARG=MacOSX
-#OBJTYPE=power

 #Configurable parameters

 <at>  <at>  -26,6 +24,8  <at>  <at> 
 	$DEVS\
 	$PORT\

+LIBNAMES=${LIBS:%=lib%.a}
+
 HFILES=\

 CFLAGS='-DROOT="'$ROOT'"'\
 <at>  <at>  -35,23 +35,19  <at>  <at>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Forsyth | 5 Dec 2010 22:20

Re: macosx build

aha! i think something else is wrong.
i can see now see why it looked like a bad substitution, though,
which confused things. i'll have something to test shortly.
Permalink | Reply | 0 comments |
headers
Robert Ball | 15 Dec 2010 16:18
Favicon

interesting limbo syntax

hey all,

found this interesting bit when perusing some acme-sac code
(/appl/cmd/os.b):

	sys->stat(p).t0 != -1

where the stat function returns a tuple of (int, Sys->Dir).

is this standard/accepted, or perhaps a temporary hack that has
outlived its life expectancy?  is there a historical basis in
another language from which this was taken?

either way, it made me laugh...it's always great running across
unexpected language features.

best,

r
Permalink | Reply | 10 comments |
headers
Jeff Sickel | 15 Dec 2010 16:49
Favicon

Re: interesting limbo syntax

In short, see section 8.1.3 in "The Limbo Programming Language" document.

-jas

On Dec 15, 2010, at 9:18 AM, Robert Ball wrote:

> hey all,
> 
> found this interesting bit when perusing some acme-sac code
> (/appl/cmd/os.b):
> 
> 	sys->stat(p).t0 != -1
> 
> where the stat function returns a tuple of (int, Sys->Dir).
> 
> is this standard/accepted, or perhaps a temporary hack that has
> outlived its life expectancy?  is there a historical basis in
> another language from which this was taken?
> 
> either way, it made me laugh...it's always great running across
> unexpected language features.
> 
> best,
> 
> r
>
Permalink | Reply | 5 comments |
headers
Noah Evans | 15 Dec 2010 16:51
Picon

Re: interesting limbo syntax

I end up wishing I have that particular syntax in Go quite often.

Noah

On Wed, Dec 15, 2010 at 4:18 PM, Robert Ball <rtb@...> wrote:
> hey all,
>
> found this interesting bit when perusing some acme-sac code
> (/appl/cmd/os.b):
>
>        sys->stat(p).t0 != -1
>
> where the stat function returns a tuple of (int, Sys->Dir).
>
> is this standard/accepted, or perhaps a temporary hack that has
> outlived its life expectancy?  is there a historical basis in
> another language from which this was taken?
>
> either way, it made me laugh...it's always great running across
> unexpected language features.
>
> best,
>
> r
>
Permalink | Reply | 0 comments |
headers
roger peppe | 15 Dec 2010 17:10
Picon
Gravatar

Re: interesting limbo syntax

the copy of the document that i can see doesn't mention tuples in that
section...

On 15 December 2010 15:49, Jeff Sickel <jas@...> wrote:
> In short, see section 8.1.3 in "The Limbo Programming Language" document.
>
> -jas
>
> On Dec 15, 2010, at 9:18 AM, Robert Ball wrote:
>
>> hey all,
>>
>> found this interesting bit when perusing some acme-sac code
>> (/appl/cmd/os.b):
>>
>>       sys->stat(p).t0 != -1
>>
>> where the stat function returns a tuple of (int, Sys->Dir).
>>
>> is this standard/accepted, or perhaps a temporary hack that has
>> outlived its life expectancy?  is there a historical basis in
>> another language from which this was taken?
>>
>> either way, it made me laugh...it's always great running across
>> unexpected language features.
>>
>> best,
>>
>> r
>>
(Continue reading)

Permalink | Reply | 4 comments |
headers
roger peppe | 15 Dec 2010 16:54
Picon
Gravatar

Re: interesting limbo syntax

yeah, it's not documented but quite useful.
tuples are just like adts with members named t0, t1, t2 etc.

i found it in a similar way to you.

On 15 December 2010 15:18, Robert Ball <rtb@...> wrote:
> hey all,
>
> found this interesting bit when perusing some acme-sac code
> (/appl/cmd/os.b):
>
>        sys->stat(p).t0 != -1
>
> where the stat function returns a tuple of (int, Sys->Dir).
>
> is this standard/accepted, or perhaps a temporary hack that has
> outlived its life expectancy?  is there a historical basis in
> another language from which this was taken?
>
> either way, it made me laugh...it's always great running across
> unexpected language features.
>
> best,
>
> r
>
Permalink | Reply | 1 comment |
headers
Oleg Finkelshteyn | 15 Dec 2010 17:25
Picon
Gravatar

Re: interesting limbo syntax

> found this interesting bit
>       sys->stat(p).t0 != -1
> is there a historical basis in
> another language from which this was taken?

I can't speak for Limbo's designers, but an equivalent syntactic
feature called record selector exists in Standard ML. The use of
selection you quoted, x.t0, might look like
    #1 x
(in SML, tuples are records having consecutive integer labels for data members).
Permalink | Reply | 0 comments |
headers
Jeff Sickel | 15 Dec 2010 17:40
Favicon

Re: interesting limbo syntax

Looks like the html versions out there haven't been regenerated in a while.

plumb limbo.ms:1637.

	In the second case, the term must yield a value of a tuple type,
	and the identifier must have the form tn where n is a decimal
	number giving the index (starting from 0) of an element of the
	tuple.  The result is the value of that element.

On Dec 15, 2010, at 10:10 AM, roger peppe wrote:

> the copy of the document that i can see doesn't mention tuples in that
> section...
> 
> On 15 December 2010 15:49, Jeff Sickel <jas@...> wrote:
>> In short, see section 8.1.3 in "The Limbo Programming Language" document.
>> 
>> -jas
Permalink | Reply | 2 comments |

Gmane