Re: Another idea from pick goes mainstream...
- From: "Albert D. Kallal" <kallal@xxxxxxx>
- Date: Sat, 15 Apr 2006 00:09:45 GMT
Pick was not the first system to use paged
memory by any means - it probably was the first to implement the idea
of frames in such a manner - but I would not even be so sure of that.
I make no such claim, or even HINT that the virtual memory, and how
page faults work in pick was a invention of pick, or somting that was
pick ONLY HAD. However, I am MOST certainly saying it had such
a system by design, and had so from day one. No, it was not the first,
it certainly was a EARLY adopter of such a page fault system. Further
it was at least 10+ years later that these types of features became standard
fair for *most* OS platforms...including UNIX. So, no, it was not the first
by
any means..but it had a feature that hit mainstream, and was touted by all
vendors a good 10 years later as a great feature of a good OS.
As I said, this seemed to happen so often with pick.
Hence both Pick and UNIX had ways to use virutal memory, and UNIX was
developed and advanced and Pick was not. UNIX demand paged memory was
not stolen from Pick
Again, I made no such claim, or even remotely suggested that....
Well, again, be careful, because varaible length records were not new
to Pick particularly.
Of course they were not. Again a silly presumption on your part. however,
MOST
databases of the time were fixed length systems, and based on a record
numbers
To calculate the position of the 5th record in the file...the record size X
# of records was used.
Pick never did have record numbers, and when sql systems in the early 80's
came along (a good many years after pick), they also had this concept of
NO record numbers....and some did have variable length records...some
systems did not. My point was that after a considerable amount of years in
our
industry, VIRTUALLY ALL vendors of database products now offer
variable length fields. Again this is standard fair today..but many years
ago,
a variable length record was considered state of the art in database
systems.
All of a sudden, vendors were pointing out how great of a feature
variable length records and fields was....and pick had it for years
and years. Again...not the first to have it..but
it was just another feature in a LONG LIST of features that was to go
mainstream....
I suspect that Ken used a pcode
for Pick BASIC because it was the easiest way to fit it in; I also
prefer to think that he wrote it so he could write Star Trek for Pick,
though he denied it. I also think that the birdmen are coming... ;-)
Sure, and the developers of Java, and even MS used the same arguments
to save time and money. Again the issue is that both the pick virtual
machine, and
the programming language where p-code systems
Ultimate, one of the more successful vendors of the 80's and 90's, they
built custom processors that execute the pick assembler op-codes
directly.
To be fair, or other machines/processors, the pick assembler
was cross-assembled to NATIVE code for the given processor
NEVER THE LESS, the design was a virtual operating system.
This is exactly why so many vendors in the 80's appeared,
and so many DIFFERENT processors could run the pick system
due to be being EASY to port to a new chipset.
This is EXACTLY the same arguments we hear today for
Java, and the .net runtimes. And, yes the BASIC programming
language was of course p-code, but my point still stands that
for appcation development today p-code has gone mainstream....
BASIC on a pc was also popular and used p-code (well, VB actually did have
a native compiler for that last few versions before vb.net). Regardless,
MAJOR vendors of major development platforms did not as a general rule adopt
p-code systems until Java and .net hit the scene. So, again, pick not
first...but again it certainly was the right design decision --- even if
done out of necessary...we see the SAME arguments today from the mainstream
vendors as to why a p-code and common runtime is a good design choice...
A JIT compiler can still be a good idea, but it
is sad if you MUST have it for performance.
Well, with pick it was not that long ago we received native compile options
(and, most of us avoid that option anyway).
As mentioned, MOST implementations of the pick os did cross
compile...however a few notable exceptions was companies like Ultimate.
built processors to execute the pick assembler op-codes direct. That means
you built a processor or something else to EXECUTE THE pick virtual
assembler code instructions. Even their Ultimate pick version for the IBM pc
executed pick assembler op-codes (since they did not want to build a custom
board that worked in the IBM pc, nor cross assembler the OS - they simply
wrote a op-code interpreter for the pick virtual machine). I want to STRESS
that we are NOT taking about the BASIC language here, but the OS WAS ALSO
written in pick assembler, which in term was executed by the host processor.
Pick systems r83 version for the IBM pc was cross-assembled op codes and
thus it ran native to the host processor (so, picks r83 was about 3-8 times
faster on the IBM pc then Ultimate's version for the PC). So, do keep in
mind we have the p-code for the BASIC programming langue, and then we have
what is called the pick virtual machine op codes, or what is commonly
referred to p-code. The first to do this? of course not!, but it was a
complete virtual machine from top to bottom.
Well, again, XML can easilly model the delimited strings of Pick, but
Pick cannot easilly model the things that XML can.
Why can't a mv record model the same structure as XML? the ONLY difference
here is that pick does not have a standard format for representing the field
names in the text stream like xml. The fact remains that XML is simply a
string with delimiters..and that is what pick records are also.
At the end of the day though, the fact that XML can easily model a Pick
delimited record is just coincidence, as XML, even in its original
formulation contains much that PIck does not.
Well, ask yourself what feature in XML is any better then a CSV or "dif"
format text file that was popular in the 80's and 90's?
THE BIG DEAL here is that the format for the data used is TEXT data..and NOT
BINARY format. Again this means that STORAGE of the data is going text in
our industry. Remember, even numbers in a pick system are stright ASCII
charangers...and so are they in XML.
XML is really about about a text format to repesnlty what was USEALLY stored
in a binary fomrat. If XML was a binary format like dbaseIII, it would not
be a big deal at all. The real big deal of XML is that you can have
repeating data sets, and also that is it text. The problem with a CSV file
is that you can have a mix of non, and repeating data sets (so, you have
MUCH difficlty repstlty a invoice in a CSV string..but in a XML, or a pick
reocrd you can do this with ease). XML is no better then a csv file when you
have the first row definfing the field names. However, it is the ability to
have repdating data..and this is EXACLTY WHAT pick reocrds also have.
I don't know if you every written anyh pick assuelbery code (I have). You
will note that the string processing and delimtoer suprot is avialing at the
pick assemblery lanauge level (the virtal mahcine). The fact is again that
the minstaron industrying is adopred a text string that can repserlty
reapding and non repdaing data in the SAME string. Furhter, that data is NOT
in binary format..and it is exaclty what a pcik reocrd has been for 30+
years...
It is a brialty deisng..and I am sure pick is not the first to have
delomtoned text...but XML is really the same concpet...excet 30+ yeras
later....
The term multi-valued is unfortunate, but only for Pick and MUMPS.
Multidimensional means something else here.
No..it is not a unfortunate use of the term. It has the SAME context as a
true MV field. Even the SQL QUERY'S built in ms-access will recognize these
fields with multiple values. You do NOT have to write a sql join to use
these new MV fields in ms-access.
select * from tblCustomers where FavorateColor = "red" or "blue"
The above will now work in ms-access for a SINGLE costumer record in
ms-access with a mv field, or what they are calling a complex data field.
The example above has a multi-value field called FavorColor..and it can hold
more then one value...and be used in a query. I don't know of ANY sql
environment today that has this feature (except of course the pick query
language).
So, we are seeing the start of MV extensions to sql today....
--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx
http://www.members.shaw.ca/AlbertKallal
.
- References:
- Another idea from pick goes mainstream...
- From: Albert D. Kallal
- Re: Another idea from pick goes mainstream...
- From: Jim Idle
- Another idea from pick goes mainstream...
- Prev by Date: Re: A trip down memory lane: ADVENTURE for Pick beta release
- Next by Date: Re: Another idea from pick goes mainstream...
- Previous by thread: Re: Another idea from pick goes mainstream...
- Next by thread: Re: Another idea from pick goes mainstream...
- Index(es):
Relevant Pages
|
